fix(auth): report the status when a request is rejected without a body

[ExtraToast]

Summary

A request rejected by a servlet filter carries no ProblemDetail body. unwrap read error === undefined, fell through to data == null and threw Error('Missing response body'); the store's isProblemDetail check then failed and the form showed "Login failed" — a message that names neither the status nor the fact that the server refused the request before reading it.

That message cost a full investigation. A sign-in failure reported as a 401 turned out to be /api/oauth2/authorize answering 401 to a non-HTML Accept (JorisJonkers-dev/auth-api#59), and the session-login attempts that followed were 400 invalid-credentials — wrong credentials, which the form also reports as "Login failed" whenever the body cannot be read. The status is the one fact that separates "your password is wrong" from "a filter refused this", and the SPA discarded it.

Fix

ClientResult now carries the Response. isRejected treats a non-ok response as a rejection even when the client reports no error payload, and rejectionOf synthesizes a ProblemDetail from the status when there is no body to read:

The server rejected the request with status 401.

An error response that does carry a ProblemDetail is passed through untouched, so every existing message — including the 400 invalid-credentials detail the API does return — is unchanged.

Verification

• New test in authService.test.ts drives a bodyless 401 through sessionLogin and asserts the thrown value carries status and the status-bearing detail. Proven to fail before the fix by reverting the isRejected response check — it threw Error('Missing response body').
• pnpm test — 124 tests passed across 13 files, on main at release 0.4.4.
• pnpm lint (--max-warnings 0) and pnpm typecheck — clean.

Risk

• Low, and confined to the failure path: a successful response never reaches either new function, and an error carrying a body keeps its own detail.
• The synthesized detail names a status rather than a cause, which is deliberate — it is the only thing known about a rejection that never reached a controller.

Links

• The reported incident and its actual cause: fix(auth): redirect to login from authorize whatever the Accept header auth-api#59.
• Hardening found during the same investigation, not its cause: fix(auth): keep a stale bearer token from blocking sign-in auth-api#57.