server: anonymous LIST of users returns 403, not 200 with an empty array

Found while re-verifying the security posture against the public hostname now
that the server is internet-exposed. pb_hooks/main.pb.js covered bookcases,
shelves and books but never users, so an anonymous GET of the accounts
collection answered 200 with an empty array.

Nothing leaked: two real accounts exist and the declarative listRule filtered
both out, so no account, email or id was ever visible to an anonymous caller.
But "200 with []" is the exact wrong signal this hook exists to remove — some
clients read it as an allowed request — and the accounts collection is the last
place to leave it. Defensible while the server was localhost-only; not now.

Re-verified over the internet after restarting the service: books, shelves,
bookcases and users all 403 anonymous, self-registration 403, health 200.

Also re-verified that login still works, since this hook now runs on a
collection the app authenticates against: auth-with-password returns 200 with a
token, and an authenticated LIST of all four collections still returns 200. The
hook rejects unauthenticated list/search only, and auth-with-password is not a
list request.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPpdG8VnRfS3KkisR3HUAE

docs/HANDOFF.md

@@ -107,16 +107,23 @@ Consequences that were not true when the app was designed:
 | `GET /api/collections/bookcases/records` | **403** |
 | `POST /api/collections/users/records` (self-registration) | **403** |
 | `GET /api/health` | 200 (intended — it is a health check and leaks nothing) |
-| `GET /api/collections/users/records` | **200 `{"items":[]}`** — see below |
+| `GET /api/collections/users/records` | **403** (was 200 `{"items":[]}` — fixed same day, below) |
 
-**Known gap, not a leak:** `users` LIST answers **200 with an empty array** instead of
-403. No data escapes — there are two real accounts in the DB and an anonymous caller
-sees neither, because `listRule` filters the rows out — but the status code is wrong
-and it is the exact PocketBase quirk `pb_hooks/main.pb.js` exists to paper over. That
-hook lists only `bookcases`, `shelves`, `books`; `users` was never added to it. One
-word of a fix, and worth doing now that the collection is world-reachable: some
-clients read "200 with []" as an allowed request. **Not yet done — do not record it as
-done until the curl above returns 403.**
+**The `users` gap, found and closed on 2026-09-12.** `users` LIST was answering **200
+with an empty array** instead of 403. No data escaped — there are two real accounts in
+the DB and an anonymous caller saw neither, because `listRule` filters the rows out —
+but the status code was wrong, and it was the exact PocketBase quirk
+`pb_hooks/main.pb.js` exists to paper over. That hook listed only `bookcases`,
+`shelves`, `books`; `users` was never added, which was defensible while the server was
+localhost-only and is not now that the collection is world-reachable.
+
+Fixed by adding `"users"` to the hook's collection list and restarting the service.
+Re-verified over the internet **after** the restart: all four collections 403 anonymous,
+self-registration 403, health 200. Login was re-verified too, because this hook runs on
+a collection the app authenticates against: `POST /api/collections/users/auth-with-password`
+still returns 200 with a token, and an authenticated LIST of all four collections still
+returns 200. The hook only rejects UNAUTHENTICATED list/search, and auth-with-password
+is not a list request.
 
 ## STATE: what is DONE
 ### Wave 1A — server: COMPLETE and verified by the orchestrator (not just self-reported)