fix(web): load every page of organizations, not just the first 50 (#3446)

[bdunncompany]

Closes #3446. Verified @_jrush's report against origin/main before changing anything — it reproduces exactly as described, and the cause is client-side.

Why it happens

GET /orgs/organizations paginates correctly and returns { data, pagination: { page, limit, total } }. The page never asks for more than the first page:

const response = await fetchWithAuth('/orgs/organizations');   // no page, no limit

getPagination defaults to limit=50, so 50 rows come back and pagination.total is discarded. Search is organizations.filter(...) over whatever was loaded (OrganizationsPage.tsx:78-81), which is why an org past the first page returns "No organizations match your search" even though the API knows about it — the search is filtering a list that never contained it.

Worth stating because it rules out the obvious one-line fix: raising the limit cannot work. getPagination is Math.min(100, ...), so the server clamps to 100 per request regardless of what is asked for. Any tenant past 100 orgs still loses rows. The page has to walk the pages.

The fix

fetchAllOrganizations walks every page and is exported so it can be tested without mounting an 876-line component that pulls in routing, i18n, drag-and-drop and Pax8.

It requests limit=100 — the server's ceiling — so the common case costs one request and a 250-org tenant costs three.

Two termination conditions on purpose:

• short page — the primary signal, and the only one that works for a legacy or unpaginated response that returns a bare array with no pagination block;
• total reached — the fast path when the server reports it.

Plus a MAX_PAGES stop at 100 (10k orgs). A wrong or missing total combined with a server that keeps returning full pages would otherwise spin forever in a browser tab; a bounded stop degrades to "some orgs missing", which is the current behaviour, rather than a hung page.

null from the fetcher propagates so the existing 401-redirect path still aborts without rendering.

Verification

Control run: with the loop bounded to a single page — i.e. the pre-fix behaviour — 3 of 7 tests fail, including walks every page, not just the first. The other 4 cover the shapes and guards and pass either way, which is what they are for.

7 new tests: multi-page walk (250 orgs across 3 pages, asserting org-51 — the first row the old cap hid — is present), that it requests the server ceiling, short-page termination with no pagination block, the {organizations:[...]} shape, the MAX_PAGES stop against a server that never stops, null propagation for the 401 path, and that a mid-walk fetch error escapes rather than silently truncating the list.

• tsc --noEmit (apps/web) — exit 0. It caught a real gap on the first pass: the helper returned unknown[] where setOrganizations wants Organization[], so it is generic and the call site is fetchAllOrganizations<Organization>.
• vitest run (apps/web, full suite) — 559 files / 5392 passed, exit 0.
• One file changed, +59/−15, plus the new test file. No API changes.

Not addressed

The API side is untouched: limit still clamps at 100, which is correct for an API. If you would rather the page show a paged table than load everything, that is a different change — this one keeps the existing render-all-and-filter-client-side design and just stops it lying about what "all" means.