fix: stop 500s when an account has no usable PDS credentials

[CountableNewt]

Fixes the 500 on GET /v1/accounts/:did/schedules reported on the dev instance, and adds the reconnect handling that the fix makes necessary.

Root cause

Listing schedules resolves brand permissions first, which walks every managed account and calls listRecords for each. authenticatedSession sat outside the do/catch that falls back to cached records, so any account without an OAuth session row threw notConfigured and the request became an opaque 500 — for every user, not just the account at fault.

Dev hit this constantly because dev/seed inserts six accounts with no OAuth sessions. Prod is exposed too, just less often: any real account whose token is revoked or expires produces the same 500 for everyone.

The bug was invisible to tests because InMemoryPDSClient returns [:] for unknown DIDs instead of throwing.

Changes

Read path — listRecords and getRecord now wrap the session lookup, so a missing or rejected credential reads through to the local cache the same way an unreachable PDS already did.

Detection — because reads now degrade quietly, a dead token would otherwise look healthy until the next publish. PDSClientError.isAuthFailure is now the single definition of "credentials are gone" (notConfigured, 401/403, invalid_grant), shared with ScheduleWorker.classify so the two can't drift. A read that falls back for auth reasons marks the account needs_reauth; transient failures (503, 429) deliberately don't.

Write path — writes still can't succeed without credentials, so auth failures map to 409 account_needs_reauth instead of a 500. Deliberately not 401: the Skej session is valid, only the PDS credential is dead, and a 401 reads as "signed out" and would bounce the user to sign-in.

Diagnosability — ErrorMiddleware swallowed unhandled errors silently, which is why this surfaced as a bare 500 with nothing to go on. It now logs method, path, and the reflected error.

UI — needs_reauth was previously set only by the worker and read by nothing. requestJSON now throws SkejApiError carrying the error code; a banner names the stale account and offers a Reconnect that starts OAuth with the handle prefilled; both account pickers mark stale accounts; the settings page gains a status badge and its own reconnect card.

Verification

• 70 Swift tests, 21 web tests, lint and typecheck all green.
• Regression tests added at the defect site — both failed with Caught error: .notConfigured before the fix.
• Exercised end to end in a browser against a local API: flipped an account to needs_reauth, confirmed the banner and picker warning appear, clicked Reconnect, confirmed the account returned to active and the banner cleared.
• Verified on the dev instance.

Prod notes

Prod runs SKEJ_PRO_ENABLED=false. The Connected Account card sits outside the Pro gate so both reauth surfaces work, and /v1/accounts filters to self — so prod won't see the seeded-demo-account noise that dev does.

🤖 Generated with Claude Code

[CountableNewt]

Closing in favor of a topic branch off main. This repo squash-merges to main, so a dev -> main PR has a merge base of 64952ad and tries to re-apply the three commits main already holds as squashes (#15, #16, #17), producing spurious conflicts. Reopening as a single cherry-picked commit off main — the content delta is identical.