fix: accept Bearer prefix on public API key auth

[giladresisi]

What kind of change does this PR introduce?

Bug fix (backend, public API auth). PublicAuthMiddleware.use now strips an optional Bearer prefix (case-insensitive) from the Authorization header before matching it against the organization's API key or a pos_ OAuth token. Previously the header value was matched as an exact string, so any client sending the conventional Authorization: Bearer <key> form got a 401 "Invalid API key" even though the key itself was valid. Everything after the prefix strip - key lookup, OAuth token path, subscription check - is unchanged.

Why was this change needed?

A support ticket (August 2026) from a customer running unattended publishing automation against the public API reported intermittent 401s "even though the API key is valid and stored unchanged". Investigation found nothing server-side that would 401 a valid key; the one client-side shape that reproduces it exactly is some code paths adding the standard Bearer prefix while others send the raw key. Accepting both forms removes the whole failure class and matches how most HTTP clients and SDKs send tokens by default.

Other information:

Came out of a support-ticket investigation together with two sibling PRs improving Instagram and Threads container-error messages; each is independent.

QA

Tested end to end against a running backend: raw key, Bearer <key> and lowercase bearer <key> all return 200 with the org's integrations; a wrong key returns 401 "Invalid API key" with and without the prefix; a missing header still returns 401 "No API Key found".

1. Run the backend and take an organization's API key from Settings
2. curl -H "Authorization: <key>" http://localhost:3000/public/v1/integrations - expect 200 with the integration list
3. curl -H "Authorization: Bearer <key>" http://localhost:3000/public/v1/integrations - expect the same 200 (was 401 "Invalid API key" before this fix)
4. curl -H "Authorization: Bearer wrong" http://localhost:3000/public/v1/integrations - expect 401 "Invalid API key"
5. curl http://localhost:3000/public/v1/integrations with no header - expect 401 "No API Key found"

Checklist:

• I have read the CONTRIBUTING guide.
• I have signed the Contributor License Agreement (CLA) (ICLA for individuals, CCLA for entities).
• I confirm I have not used AI to submit this PR or generate code for it.
• I checked that there were no similar issues or PRs already open for this.
• This PR fixes just ONE issue
• I have filled in the QA section above with real steps to verify this change.

[strix-security]

Strix Security Review

No security issues found.

_{Updated for c90e312.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[postiz-agent]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.