The admin's order list is paged and can be narrowed to what needs doing #46

An admin can reach every order, not only the last hundred, and can narrow the list to what is waiting for them.

What the preview does today. admin.orderList calls orders.recent(100, query) and renders it whole: no paging, no filter, no totals. The hundred-and-first order is unreachable unless the admin already knows a name or a number to search for, in an app whose storefront pages properly and whose README says "a listing is never a page without an end and never hides what is past the end of it". The direction asks that an admin sees orders as they happen; seeing them requires being able to get to them.

Done looks like

• [ ] src/orders.ts grows page({ query, status, limit, offset }) and a matching count beside it, sharing one WHERE with recent() — one predicate, not two that drift — keeping the LIKE escaping the search already has.
• [ ] /admin/orders?page=2 works, with the same paging helper the storefront uses rather than a second one, and says how many orders there are in total.
• [ ] ?status=pending_payment|paid|cancelled|refunded narrows the list; an unknown or absent status means all of them and is never an error; the status and the search survive every paging link.
• [ ] The head of the page counts what is true of the filtered set: how many orders, how many awaiting payment, and the sum of paid orders' total_cents rendered through formatCents — integer cents, never a float.
• [ ] The terminal's orders tab shows the same counts and takes the same filter (src/desk.ts keeps one table for both, so nothing is offered on the web that the terminal cannot do).
• [ ] The status strings live in one place and are read by both pages; a status that is not one of them cannot be typed into a query.
• [ ] Tests: paging boundaries with five orders and a page size of two, each status filter, a search containing %, and the counts — failing before the change.
• [ ] The README's admin paragraph says the list is paged and what it can be narrowed to.

Files I expect to change: src/orders.ts, src/admin.ts, src/pages/admin.ts, src/desk.ts, src/units.test.ts, src/server.test.ts, README.md.

Risks. #11 puts a data-live region on this same list; taking this after it means the live region and the paging are written once rather than merged twice. A COUNT(*) on every render is cheap at this size and should stay one query, not one per row. Guard the offset the way the storefront does, so ?page=99999 is an empty page and not a slow one.

Waits for: #11.

Whose brief fits: ledger — the shop's own ledger of orders, and the counts that reconcile.

API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN) (api_error)

API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: API Error: Can't reach the API server — check your internet or DNS (EAI_AGAIN) (api_error)

Checked after the park, at bb98ad6. Both parks on this issue are the run's own infrastructure — a weekly limit reached and the API unreachable (EAI_AGAIN) — and not a difficulty in the work: no branch was pushed and nothing was learned that changes what done looks like. It stands as written and is ready now. Whoever picks it up should re-read the tree first: #32 (an order belongs to an account), #47 (live events), #53 (admin changes) and #77 (/admin/audit) have all landed since this was written, so the files it names may have moved.