Test the account refresh after a rejected token: signed out, credential gone, unchanged, and a refresh the server refuses

## What happens

`Sources/UttrflowAccount/HTTPAuthenticationService.swift`, `currentProfile(ifChangedFrom:)` and `renew()`, has these branches that have never run:

- line 279: `authorised()` answering `.noCredential` at the start;
- lines 288 and 290: after a 401, `renew()` answering `.sessionOver` (becomes `.signedOut`) or `.noCredential`;
- line 293: the retried request answering 304, which becomes `.unchanged`;
- line 361: `renew()` with no refresh token;
- lines 371-373: a refresh answered with a non-401 failure, or a body that doesn't decode, which throws;
- lines 390, 408, 413 and 420: a sign-in whose issued session or profile can't be read, whose session is already over, or whose profile request fails.

The existing tests cover one retry after a 401 that succeeds, and a second 401.

Measured on origin/main `26d7bc1` with `swift test --enable-code-coverage` (5,384 tests, all passing) and `xcrun llvm-cov export` over the test binary. The regions named below have an execution count of 0: no test runs them, so a change that breaks them passes `make verify`.

## Why it matters

These decide whether a Mac stays signed in. A wrong answer either signs someone out on a network hiccup or keeps showing an account whose session the server ended. The sign-in failures must refuse the sign-in rather than fall back to a stale cached profile, as the comments on lines 405 and 409 say.

## How to reproduce

Run `swift test --enable-code-coverage`, then `xcrun llvm-cov show -instr-profile .build/debug/codecov/default.profdata .build/debug/UttrflowPackageTests.xctest/Contents/MacOS/UttrflowPackageTests Sources/UttrflowAccount/HTTPAuthenticationService.swift` and look for the `0` counts on the lines named above.

## Acceptance criteria

- With the stub transport answering `/me` with 401, then `/v1/auth/refresh` with 401: `.signedOut`, and the token store is cleared.
- `/me` 401, refresh 200, retried `/me` 304: `.unchanged`.
- Refresh answered 500, or 200 with `{}`: throws the refusal, and the token store keeps its refresh token.
- A sign-in whose session body is `{}`: throws `.providerRefused`, and nothing is stored.
- Each new test fails when the branch it covers is broken. Check this by hand before opening the PR: temporarily change the branch (flip the condition or return the other value), see the test fail, then restore it.

## Where to start

- `Tests/UttrflowAccountTests/HTTPAuthenticationServiceTests.swift`. The test `oneRetryAfterA401` is the template, and `Tests/UttrflowAccountTests/BackendSupport.swift` has the stub transport and JSON builders.
- `Tests/UttrflowAccountTests/AccountSupport.swift` has an in-memory token store.

Read `CONTRIBUTING.md` first. Iterate with `swift test --filter `, then run `make verify` before pushing. Only tests change; no product code needs to.

**Size:** M.

Read CONTRIBUTING.md, then use oneRetryAfterA401 in Tests/UttrflowAccountTests/HTTPAuthenticationServiceTests.swift as the template. Inspect BackendSupport.swift for the stub transport and JSON builders and AccountSupport.swift for the in-memory token store; run filtered Swift tests while covering the listed authentication branches. Done means each acceptance case has a failing-when-broken test, then make verify passes.

Written by the indexing model from the issue text.