fix: send a token on change-password and logout, and six other audit defects

[rghvgrv]

Resolves the audit tracked in #184. Nine of the ten slices are implemented; one was withdrawn after it turned out to be wrong.

Closes #185
Closes #186
Closes #187
Closes #188
Closes #190
Closes #191
Closes #192
Closes #193
Closes #194

The one that mattered

A user could never change their password from the app, and signing out did not end the session.

IAuthApi is registered without AuthDelegatingHandler — deliberately, since it carries /auth/refresh and chaining the handler there would let a 401 during refresh recurse into refresh. But change-password and logout also lived on it, and both are [Authorize]. Neither ever sent an Authorization header.

Change-password answered 401 every time. SettingsViewModel maps 401 to "Session expired, please log in again.", so the user re-authenticated, retried, and got the same message forever.

Logout was worse. It returns IApiResponse, which does not throw on a non-success status, so the 401 sailed past the catch and read exactly like a successful revoke. The client cleared its local tokens while the refresh token stayed live server-side for its full 30-day lifetime — a token lifted from a device backup outlived an explicit sign-out.

Fixed by splitting both calls onto a new IAccountApi registered with the handler attached. IAuthApi keeps the anonymous endpoints and stays handler-free.

The durable part is RefitClientCompositionTests. It builds the real container and sends a real request through each client into a capturing primary handler, asserting every client with [Authorize] endpoints carries a bearer token and that IAuthApi does not. I verified it fails when a handler registration is removed. Nothing asserted this before — the mobile tests substitute fakes and the API tests supply a token directly — which is exactly how two defects shipped together and sat there.

The rest

Issue	Fix
#188	FX refresh accumulated rates and upserted only after the loop, so one bad currency threw past the upsert and discarded the whole pass. Now isolated per currency; a total outage still logs at Error so the signal is not downgraded.
#190	forgot-password returned after one SELECT for an unknown address vs. ~5 queries plus an insert for a known one. Code generation and hashing hoisted above the lookup. Residual gap documented in code — see below.
#191	An update carrying a stale version but no actual changes returned 200. EF marks nothing modified, issues no UPDATE, so the xmin predicate never ran. That is the shape the check exists for: a user who opened the edit screen before a mark-paid and changed nothing.
#192	Cache mirrored neither Version nor CatalogId. Latent today, but a save built from a cached row would 409 forever and silently strip the catalog link. Version is nullable so a pre-upgrade row is not read as an authoritative 0.
#193	The IsFreeTrial guard sat after the OneTime branch returned, so a free-trial one-time purchase counted in full.
#194	GET /users/me returned 200 with a null body for a vanished row; PUT has always returned 404.

Withdrawn: #189

I filed it, and it was wrong. MarkPaid_TwiceInARow_AdvancesTwoCycles already pins the behaviour I called a defect, with the rationale inline: "Someone clearing a backlog pays one period per tap." Advancing two cycles on two taps is deliberate — it is how a backlog is settled, and it matches the rule in CLAUDE.md that the date steps one cycle from the date just settled rather than skipping to today.

I implemented the "fix", hit that test, and reverted. MarkPaidAsync is byte-identical to main. I had audited the method without reading the test documenting its intent. Closed as invalid with the full reasoning on the issue.

Judgement call on #190

Full timing parity would mean performing throwaway DB writes for addresses with no account — real write load driven by anyone who can reach the endpoint. Chose partial parity instead: both branches now pay for the CSPRNG draw and the SHA-256, and the residual (a known address still costs extra round trips) is documented in the code with its reasoning, so a later refactor does not silently reverse it. The remaining signal is a few milliseconds of database time rather than the ~250ms BCrypt asymmetry the register and login paths exist to erase, on an endpoint already IP rate-limited to 10/min.

Verification

All four CI jobs reproduced locally against the final commit:

Suite	Result
SubVora.Application.Tests	55 passed
SubVora.Infrastructure.Tests	109 passed
SubVora.Api.Tests	157 passed
SubVora.Mobile.Tests	330 passed
Android package (net10.0-android, Release, APK)	built clean

Two fixes were additionally proven by disabling them and watching the new test go red:

• Detect a stale version on an update that changes nothing #191 — without the fix: Expected: Conflict, Actual: OK.
• Fail the build when an authenticated Refit client is missing its auth handler #187 — removing AddHttpMessageHandler from IAccountApi fails only that client's case; the other seven still pass.

No schema change, no migration, no new dependency. The only API contract change is additive: GET /users/me may now answer 404.

.secrets.baseline was re-staged twice for line-number drift only — inserting tests shifted existing is_secret: false entries. No new findings, and the pre-commit hook was not bypassed.