[08] Handle identifier-like searches and investigate diagnostic-looking zero-result queries #404

Implementation order: 08 of 11 category issues. 11/298 reviewed August zero-result events (3.7%).

Adds exact-lookup recovery and investigates traffic that could distort patron-demand measurements.

Dependencies: Reuse known-item lookup from #403. Diagnostic attribution can be investigated earlier without waiting for this implementation slot. This sequence is a recommended work queue, not a requirement to close every earlier issue. See #396 for the complete order.

August 2026 completed top-100 zero-result review: Opaque identifiers or diagnostic-looking text accounts for 4 of 100 ranked query rows, representing 11 recorded zero-result searches. The September 10 export ranks all 885 distinct non-empty zero-result queries without a minimum-frequency cutoff; the top 100 represent 298 events. All 100 August queries are present and categorized, and monthly totals reconcile. These are recorded searches, not unique patrons; category assignments infer intent rather than prove failure causes.

Evidence: frontend/src/data/analytics/zeroResultQueries2026.json (exported September 10, 2026; August 1 inclusive–September 1 exclusive UTC). Ordering is count descending, then query using database collation, with case preserved. Full category inventory: docs/frontend/zero-result-query-review-2026-08.md in the working change. This issue contains its complete query evidence below.

Interpretation notes:

• Rank 19: Unresolved code; possibly cadastral.
• Rank 24: Unresolved numeric identifier; compare rank 70 without assuming same patron.
• Rank 38: Looks diagnostic; attribution unverified.
• Rank 74: Opaque code or partial coordinate; no reliable interpretation.

Acceptance criteria:

• Investigate whether compact numeric/alphanumeric strings are catalog identifiers, land descriptions, or another intent; do not assign a location without evidence.
• Offer exact identifier lookup where supported and ask for context or a title when no identifier matches.
• Investigate diagnostic-looking strings such as missing_bbox using aggregate client/context evidence; do not label them bot or test traffic based on text alone.
• Keep confirmed diagnostic traffic separate in evaluation only when supported by attribution; preserve the original analytics baseline.
• Test identifiers with and without matches, numeric strings, ambiguous cadastral-like codes, and diagnostic-looking queries.
• Track suggestion impressions, acceptance, next-search nonzero results, and subsequent resource engagement using category/action aggregates; avoid collecting additional raw address or coordinate text. Distinguish lookup errors from genuine no-match outcomes.

Implementation context: frontend/src/components/search/NoResultsSearchHelp.tsx already offers keyword and Nominatim suggestions, but builds fresh search URLs that discard filters. frontend/src/__tests__/pages/SearchPage.test.tsx explicitly expects the location map to be hidden for zero results. Extend this existing experience and update focused behavior/accessibility tests. Related: #270 (zero-result analytics), #231 (Advanced Search location field).

Tracking: #396. Shared recovery, constraint preservation, and baseline validation are coordinated there. The top-100 evidence audit is complete.