fix(api): bound the search candidate set instead of draining Typesense

Fetching every match kept scoped searches correct but left the number of
round trips in the caller's hands: a one-letter query, or a deliberately
broad one, walked the whole collection a page at a time.

Cap the candidate set at 1,000 URNs — four pages — and return the
relevance-ordered prefix when the ceiling is hit. That is still far more
than one page, so the API's own authority, phase and postcode filters
keep the matches they need, while latency and upstream load stay bounded.
A capped query is logged so a genuinely truncated search is visible.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -104,8 +104,10 @@ alias-update response must never cause deletion of a potentially live index.
 The backend snapshot swap is process-local and assumes the current single-worker
 deployment. It is not an atomic transaction spanning PostgreSQL marts, Typesense
 and Next.js caches. Next.js caches are not explicitly purged by the pipeline.
-School search retrieves every Typesense candidate before applying API filters;
-only a dependency failure invokes substring fallback, not a valid empty match set.
+School search retrieves a relevance-ordered candidate prefix (currently capped at
+1,000 URNs) before applying API filters. This keeps scoped searches useful while
+putting a hard ceiling on Typesense round trips; only a dependency failure invokes
+substring fallback, not a valid empty match set.
 
 ## Deployment references