Machine-facing routes must be added to the Cloudflare Access application

Root cause of a live incident on the vetting side: a blocked applicant kept a working invite code because every revocation since #17 shipped has failed.

What happened

POST /invite-codes/disable (added in #17) returns, to the vetting Worker:

401 {"status":"error","message":"Auth Error: Request did not arrive through Cloudflare Access"}

That is AccessClient failing closed, correctly: the request carried no Cf-Access-Jwt-Assertion. It carried none because the Cloudflare Access application in front of this service is scoped to the exact path /api/invite-codes/issue. Requests to any other path are not inside the app, so Cloudflare never exchanges the service token for a JWT and passes them straight to the origin.

Confirmed without credentials:

/invite-codes/issue works. /invite-codes/disable never has. The fail-closed design held — nothing was exposed — but the endpoint was dead on arrival, and nothing at deploy time said so.

Fix (configuration)

Zero Trust → Access → Applications → this app: add /api/invite-codes/disable. Better: scope the app to /api/invite-codes/*, so the next machine-facing route is covered by default rather than by someone remembering.

Worth doing in this repo

• Document it. The README's section on AccessClient should say plainly: a new route using it must also be added to the Access application, or it will 401 in production while passing every test here.
• Make the tests say it. The existing AccessClient tests prove the extractor refuses a request with no JWT. That is the behaviour that hid this — a route outside the Access app produces exactly the response the tests call correct. A comment on refuses_every_request_when_access_is_not_configured noting that "no JWT" in production most likely means "path not in the Access app" would have shortened the diagnosis.
• Consider a startup check. Not the path config itself (the service cannot see it), but the /health endpoint could report which routes require AccessClient, so a deploy checklist has something to compare against.

Cross-reference: NorthskySocial/invite-vetting#98 adds the banner that would have surfaced this on the vetting side within a day rather than a fortnight.

Start with the README section on AccessClient and the existing test named refuses_every_request_when_access_is_not_configured. Verify the Cloudflare Access application covers /api/invite-codes/*, then document the route requirement and the production meaning of a missing JWT; completion should also include the relevant test context.