fix(auth): accept ea_* prefix in isApiKey — unblocks static-bearer path for #28

[stackbilt-admin]

Summary

Small, surgical fix. isApiKey() in src/auth.ts previously only matched the legacy sb_live_* / sb_test_* prefixes from the pre-migration stackbilt-auth era. When edge-auth took over as the ecosystem auth source of truth and started minting ea_* keys, this check was never updated — so any ea_* bearer would fall through to the validateJwt path and fail, leaving ea_* API keys effectively unreachable through the gateway.

This PR adds the ea_* prefix to the check. Purely additive — no functional change for existing sb_* keys.

Why now

This unblocks the Option B (static bearer bypass) path for the OAuth scope cluster tracked in #28/#29/#30. Currently every Claude Code / Claude.ai MCP session is silently locked out because OAuth-initiated tokens ship with empty scopes (C-1a remediation side effect). Before this merges, the ea_* fallback to edge-auth-minted API keys is impossible — the gateway literally can't recognize ea_* tokens as API keys at all.

Immediate unblock path after this merges + deploys:

1. Mint an ea_* key from edge-auth with explicit ['read', 'generate'] scopes
2. Drop into .mcp.json as the Stackbilt MCP static bearer
3. Skip the OAuth flow entirely, reach the tools directly via the API key path

Gotcha: validateBearerToken at auth.ts:53 passes scopes: result.scopes ?? [] — if edge-auth mints the key with empty scopes, Option B hits the same (none) wall from a different code path. Confirm the minted key has explicit scopes before dropping it in the config.

What this does NOT fix

• The OAuth grant-creation bug is still live. oauth: Claude Code MCP client gets zero scopes — scaffold_create unreachable from the assistant #28's Option C fix (consent-screen redirect for empty-scope initiates) still needs to ship. This PR unblocks API-key clients; it does nothing for OAuth clients.
• oauth: fall back to grant.scope when ctx.props.scopes is empty (fixes legacy grants) #29's legacy-grant fallback in resolveAuth is still needed for pre-2026-04-10 grants that have stale encrypted props.

Both of those land as separate PRs. This one exists to stop the bleeding for API-key users today while the bigger fixes cook.

Test plan

• npm run test — 120/120 green (6 files, includes auth.test.ts)
• npm run typecheck — clean
• Smoke: deploy, mint a test ea_* key, call image_list_models through the gateway — confirm it returns model list (not (none) scopes error)

Alignment

Aligns with edge-auth's own resolvePrincipal at src/security/identity.ts:44, which already accepts all three prefixes (ea_, sb_live_, sb_test_). This PR brings the gateway in line with the downstream SoT.

Related

• oauth: Claude Code MCP client gets zero scopes — scaffold_create unreachable from the assistant #28 — full OAuth scope cluster (this PR is Option B; Options C/A/others discussed there)
• oauth: fall back to grant.scope when ctx.props.scopes is empty (fixes legacy grants) #29 — legacy grant fallback (separate concern, separate PR when it ships)
• OAuth token minted for Claude.ai sessions has empty scope set — blocks all Stackbilt MCP tool calls #30 — Claude.ai session scope bug (likely dupe of oauth: Claude Code MCP client gets zero scopes — scaffold_create unreachable from the assistant #28 pending trace)
• Commit 256ba06 — C-1a remediation that created this gap