Replace Cloudflare Access with direct JWT validation in Gastown API

[jrf0110]

Context

The Gastown API (worker) currently sits behind Cloudflare Access. In production, containers need to call back to the worker at GASTOWN_API_URL, but CF Access blocks those requests because the container doesn't have CF Access credentials.

The naive fix — passing CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET into containers — is a serious security risk. Any user's agent code running in the container could exfiltrate those credentials, which grant broad access to the CF Access-protected application.

Proposed solution

1. Remove Cloudflare Access from the Gastown worker route
2. Add direct JWT validation inside the Gastown API using the NEXTAUTH_SECRET (or equivalent signing key), similar to how the main Kilo API validates requests
3. The Gastown worker already mints its own JWTs (GASTOWN_JWT_SECRET) for agent session tokens — those continue to work for container→worker auth. The additional validation is for requests coming from the Next.js app (dashboard, tRPC proxy)
4. Add the NEXTAUTH_SECRET as a secret binding in the Gastown worker's wrangler config (via wrangler secret put)
5. The Gastown API will then behave like a normal authenticated API — no CF Access edge layer needed

Acceptance criteria

• CF Access is removed from the Gastown worker route (or the route is excluded from the CF Access policy)
• The Gastown worker validates Kilo user JWTs directly using the shared signing secret
• Container→worker auth continues to work via GASTOWN_SESSION_TOKEN (existing JWT)
• Dashboard→worker auth works via the user's session JWT (validated directly)
• No CF Access service tokens are passed into containers

Parent issue

Part of #204 (Phase 3)

[jrf0110]

Closed via PR #701. CF Access replaced with direct JWT validation using NEXTAUTH_SECRET. Container→worker auth continues via GASTOWN_SESSION_TOKEN. No CF Access credentials in containers.