refactor(management): the manager pages ask a domain

[ExtraToast]

Third slice of #1167.

Why

AddressManager, CommitteeManager, RecoveryManager and UserManager read the generated client directly. ADR-001 forbids it, and #1183 listed all four as debt.

How

domains/user gains what these pages read: listUsers, readUser, listDeletedUsers, listMemberships, listAddresses, deleteUser.

Two new domains, because the alternative was putting them somewhere they do not belong: domains/committees for the committee list and its removal, and domains/recovery for which activation an account is waiting for. A committee is not the user domain's business, and neither is a recovery token's purpose.

A behaviour change worth naming

The adapters throw on a refusal rather than answering with an empty list.

CommitteeManager already worked this way — it passes throwOnError: true, catches, and reports through $handleNetworkError, and it distinguishes "could not be read" from "there are none". AddressManager and RecoveryManager did not: they checked status === 200 and otherwise called console.log. A board member with a failed read saw an association with nobody in it and no indication anything had gone wrong.

All four now report. That is a small, deliberate improvement rather than a pure move, and it is why two tests changed from asserting console.log to asserting the handler.

The tests moved with the pages

They mocked the client the pages no longer call. Each now stands in for the door its page depends on, which is also the boundary that matters when the domain's internals change.

A side effect worth having: the assertions stopped naming request shapes. expect(mockDeleteUserById).toHaveBeenCalledWith(71) says what the page meant; {path: {userId: 71}, throwOnError: true} said how the client spells it, and would have had to change again the next time the wire did.

Verification

yarn vitest run — 189 files, 1627 tests. yarn typecheck and eslint clean.

grep -rl "@/services/api" src/pages/management returns nothing, including the import("@/services/api").MembershipResponse inline type annotation that a file-level grep would have missed.

Debt list: 55 → 51.

---

Diff breakdown — █ added ░ removed, scaled to the largest row.

frontend                                          +253   -200   15
  production         ██████████████████░░░░░░░    +157    -63   10
  unit tests         ███████████░░░░░░░░░░░░░░░    +96   -133    4
  build & config     ░                              +0     -4    1

──────────────────────────────────────────────────────────────────
production                                        +157    -63
tests                                              +96   -133  0.61 test lines per prod line
total (hand-written)                              +253   -200  15 files

[ExtraToast]

Carried forward from the old file, so worth catching while this page is open: lines 138 and 205 bind @submitting, but CommitteeForm only ever emits submitted (CommitteeForm.vue:45-47, emitted at :114, :130, :135).

The handlers therefore never run, so loading and submittingId are never set and the edit and create buttons never show a saving state. A board member pressing Save on a slow connection sees nothing happen, and nothing stops them pressing again.

Tracked as #1211. I am not opening a competing PR since this file is yours right now — either fix it here and close #1211, or say and I will take it once this lands.

Found while diagnosing #1042, which turned out to be unrelated (a click landing on the wrong element mid-transition, fixed in #1212).