Freshly generated API key returns 401 Unauthorized on all /api/v1/ routes (self-hosted v0.4.8)

Summary

On a self-hosted deployment, an API key generated through Admin → API keys is rejected with 401 {"detail":"Unauthorized"} on every /api/v1/ route, even though the key is listed in the admin panel. Three separately generated keys behaved the same way.

Environment

• Image: ghcr.io/presenton/presenton:latest — logs report release: v0.4.8
• Host: Railway, single service, volume mounted at /app_data (persistence confirmed)
• Env vars set: LLM=custom, CUSTOM_LLM_URL, CUSTOM_LLM_API_KEY, CUSTOM_MODEL, IMAGE_PROVIDER=pexels, PEXELS_API_KEY, AUTH_USERNAME, AUTH_PASSWORD, CAN_CHANGE_KEYS=true, DISABLE_ANONYMOUS_TRACKING=true
• AUTH_OVERRIDE_FROM_ENV is not set (so no credential rotation is invalidating keys)

Steps to reproduce

1. Boot the container with AUTH_USERNAME / AUTH_PASSWORD set and a volume on /app_data.
2. Sign in to the browser UI as that administrator.
3. Admin → API keys → Generate key, copy the sk-presenton-... value.
4. Call the API directly over HTTPS, no proxy in between:

curl -i https://<host>/api/v1/ppt/presentation/generate \
  -H "Authorization: Bearer sk-presenton-..." \
  -H "Content-Type: application/json" \
  -d '{"content":"Consumer rights when buying online","n_slides":6,"language":"English","export_as":"pptx"}'

Expected

200 with {presentation_id, path, edit_path}.

Actual

HTTP/1.1 401 Unauthorized
{"detail":"Unauthorized"}

What was ruled out

• Key format — value starts with sk-presenton-, 53 characters, no surrounding whitespace, no duplicated Bearer prefix.
• Header shape — sent as Authorization: Bearer <key>, matching the docs example.
• Key revocation — the key is still listed under Admin → API keys at the time of the request.
• Credential rotation — AUTH_OVERRIDE_FROM_ENV is absent, so the documented "credential override invalidates existing sessions and API keys" path does not apply.
• Stale/ephemeral database — an earlier run without a volume did lose keys on redeploy; a volume was attached and keys were regenerated afterwards. Behaviour is unchanged.
• Proxy/redirect stripping the header — reproduced calling the public HTTPS URL directly, no redirect involved.

Question

Is there a prerequisite for API key authentication beyond generating the key in the admin panel — for example an account state, a multi-user setting, or an environment variable that must be enabled for /api/v1/ key auth to be honoured in v0.4.8?

Happy to provide logs or test any patch.