fix(api): a request that names a page or a size gets one

[ExtraToast]

Closes #1145.

Why

GET /users?size=500 answered with every user. Not 500 — every one.

Spring's PageableHandlerMethodArgumentResolver reads its fallback unless the request carries both page and size, and PagingConfig sets that fallback to unpaged. So naming one half of a page bought nothing, silently: the response is well formed and merely larger than the caller believed possible. A caller that names a size is one that cannot hold an unbounded answer.

Measured against four users, before this change:

request	rows	page.size
GET /users	4	4
GET /users?size=1	4	4
GET /users?page=0	4	4
GET /users?page=0&size=1	1	1

page alone was ignored too, which the issue did not know.

What this achieves

Either half means paged. ?size=1 is one row; ?page=0 is the documented default of 20. Naming neither still answers unpaged, because a listing that nobody paged is what several readers want and what unpagedByDefault is for.

How

PagingConfig now registers a resolver ahead of Spring Data's, overriding the one decision that was wrong: with neither parameter present it answers unpaged as before, and with either present it fills in 0 or 20 for the half that was not named and pages as asked.

20 is not invented — it is what the OpenAPI document already claims size defaults to, so the spec and the api now agree where before the spec described a parameter that was not honoured.

The callers, which had to move with it

Both remaining callers that named a size wanted the whole listing and were getting it by accident. Left alone, this change would have truncated them at 500 — which is exactly the bug #1139 fixed a day ago, re-created from the other side.

loadMemberAccounts and UserPicker both hold the list and filter it in the browser, so they now ask for the listing and name no size. Their behaviour on the wire is unchanged; what changed is that they say what they mean.

Worth a reviewer's attention

That both of them fetch an unbounded listing at all is a real problem — the committee picker stopped doing it in #1139 by asking the api as the reader types. These two are rarer paths (attaching a roster entry, a board membership), which is the reasoning recorded in users.ts, but the same argument that beat 500 will eventually beat "everybody". Out of scope here: this change is about the api keeping the promise its parameters make.

Verification

./gradlew :services:api:test :services:api:integrationTest — both suites pass in full.

Three new UserControllerIT cases pin all the shapes, and two of them were red first, for the right reasons: expected:<1> but was:<4> for a size without a page, and page.size expected:<20> but was:<4> for a page without a size.

yarn vitest run — 179 files, 1540 tests. One existing test asserted {query: {size: 500}} and now states the intent instead: it asks for the whole listing rather than a page whose size it would have to guess. yarn typecheck and yarn lint clean, and the generated spec does not drift.

---

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

api                                                +65    -10    2
  production         ████████████████████░░░░░░    +33    -10    1
  integration tests  ███████████████████           +32     -0    1

frontend                                            +8     -4    3
  production         ████░                          +6     -2    2
  unit tests         █░                             +2     -2    1

──────────────────────────────────────────────────────────────────
production                                         +39    -12
tests                                              +34     -2  0.87 test lines per prod line
total (hand-written)                               +73    -14  5 files