Summary

GET /api/v1/auth/me returns HTTP 500 in Core 0.14.1 when ALLSOURCE_DEV_MODE=true, even with a valid provisioned API key. This breaks Query Service (0.14.1) key validation since QS calls this endpoint to verify incoming client API keys.

Steps to reproduce

1. Start Core 0.14.1 with ALLSOURCE_DEV_MODE=true
2. Provision a tenant and API key:

   curl -X POST http://localhost:3280/api/v1/tenants \
     -H "Content-Type: application/json" \
     -d '{"id":"test","name":"Test"}'
   
   curl -X POST http://localhost:3280/api/v1/auth/api-keys \
     -H "Content-Type: application/json" \
     -d '{"name":"test-key","tenant_id":"test"}'
   # Returns: {"key":"ask_..."}

3. Call /api/v1/auth/me with the provisioned key:

   curl -v http://localhost:3280/api/v1/auth/me \
     -H "X-API-Key: ask_<provisioned-key>"
   # Returns: HTTP 500

Expected behavior

Should return 200 with the key identity (tenant_id, role, etc.), allowing QS to validate client API keys.

Actual behavior

Returns 500 Internal Server Error with no useful error body.

Impact

Query Service's AuthPipeline calls GET /api/v1/auth/me on Core to validate every incoming client request. Since Core returns 500, QS rejects all API keys with "invalid API key", making the entire QS unusable for authenticated requests.

QS ApiKeyStore ETS table stays empty because key validation always fails.

Environment

• Core: ghcr.io/all-source-os/allsource-core:0.14.1 (linux/amd64 via Rosetta on macOS ARM)
• QS: ghcr.io/all-source-os/allsource-query-service:0.14.1
• ALLSOURCE_DEV_MODE=true
• Docker Compose, local development

Workaround

None found. Core 0.13.1 was working before volumes were recreated, but the same issue appears there too after a fresh start with 0.14.1 QS.