fix(hub): CSRF guard bypasses Bearer-auth requests (legacy JWT)

[finedesignz]

Summary

Fixes a 403 csrf_failed regression for production users on the legacy JWT auth path. Symptom: clicking Scan on SupervisorPage (POST /api/supervisors/:id/scan) returns 403 in the browser.

Root cause

1. Legacy JWT login (hub/src/api/auth.ts) does NOT issue the csrf_token cookie — only the new session-cookie auth path does.
2. Frontend apiFetch reads csrf_token from cookies, finds nothing, sends the POST without X-CSRF-Token.
3. csrfGuard() rejects with { error: 'csrf_failed' }, 403.

Fix

csrfGuard() now bypasses CSRF enforcement when the request carries an Authorization: Bearer <token> header. Strict regex /^Bearer\s+\S+/i — empty Authorization:, non-Bearer schemes (Basic, etc.), and Bearer with no token all still go through normal CSRF check.

Threat model (also embedded as a comment in csrf.ts)

CSRF attacks exploit the browser's ambient-credential behavior:

• Cookies are attached cross-origin automatically — the attacker just rides them.
• Authorization headers are NOT in the ambient-credential set. Browsers never auto-attach them; JS must explicitly set them per request.
• JS on evil.com cannot read the bearer token from app.remo-code.com's localStorage (same-origin policy), so it cannot forge a Bearer-authed request.

→ A request carrying a Bearer token is, by construction, not CSRF-eligible. The double-submit cookie defense is for cookie-auth requests, where the attacker has ambient credentials but cannot read the CSRF nonce. Bearer auth has the inverse property: the attacker has no ambient access at all.

Scope guardrails

• ONLY the Bearer scheme bypasses. Custom headers (X-Auth, etc.) do not qualify — a CSRF attacker can set arbitrary custom headers via fetch() if CORS allows.
• Empty Authorization: header does NOT bypass.
• Cookie-auth users continue to use double-submit (unchanged).

Test plan

• 10 new cases in hub/test/csrf.test.ts covering the bypass + every guardrail (empty header, Basic scheme, Bearer with no token, lowercase header name, GET passthrough, cookie-auth still works without Bearer).
• All 27 csrf tests pass.
• Full hub test suite: 293 pass, 5 pre-existing failures in insert-run-started-at.test.ts (unrelated, on main since fix(scheduler.registry): ensure started_at always populated on cron fires #60).
• Post-deploy: legacy-JWT user can POST /api/supervisors/:id/scan without 403.

🤖 Generated with Claude Code