explorer: search-results '50+' label should show the real count

[rdhyee]

Symptom

The search-results line under the in-map search box reads 50+ results for "pottery Cyprus". The + is appended whenever the result set hits the hardcoded LIMIT 50, hiding the actual count — which could be hundreds or thousands.

For pottery Cyprus in the world (no area scope), there are ~7,124 matching samples (per the comment at explorer.qmd L3229). The user sees 50+. Significant under-disclosure.

Code location

• explorer.qmd L3296, L3313: LIMIT 50 on both the area-scope and world-scope queries
• explorer.qmd L3327:

  searchResults.textContent = `${results.length}${results.length === 50 ? '+' : ''} results for "${term}"`;

Suggested fix

Mirror the pattern already used by loadViewportSamples() at L2395-2415: when the LIMIT is hit, run a separate COUNT(*) query (same WHERE clause, no ORDER BY, no LIMIT) and display the real total.

SELECT COUNT(*) AS n
FROM read_parquet('${facets_url}') f
[INNER JOIN ... if area scope]
WHERE ${searchWhere}
  [${bboxSQL} if area scope]
  ${sourceFilterSQL('f.source')}
  ${facetFilterSQL()}

Display becomes: 50 of 7,124 results for "pottery Cyprus" (or similar — Hana to weigh in on copy if needed).

Considerations

• Cost: an extra COUNT scan against the facets parquet. For broad terms this is the same scan the LIMIT query already does — so it should not double the wall-clock time, just add some overhead.
• Cancellation: the search has a freshness token at searchSeq/searchAbortController; the COUNT query needs to honor it too.
• Only run COUNT when results.length === 50. Skip it when fewer rows returned — that count is the truth.

Why this matters

Without a real count, users can't tell whether 50+ means 51 or 50,000. That affects whether they refine their search or just look elsewhere. It's also a small piece of the larger trust gap around "what does the search actually do?" (related to the global-filter vs side-panel decision in #164).

Out of scope

• Whether search should restrict the map / table / facet counts (covered by Explorer state contract: URL/DOM/widget-state inventory + search-as-global-filter decision #164 / explorer: facet counts — remaining work after #157/#226 #230).
• Pagination of search results past 50 (would be a separate feature).
• Replacing the LIMIT itself with a higher cap (low value vs. just showing the real count).

Acceptance

• Search line reads e.g. 50 of N results for "term" when the cap is hit.
• Search line reads e.g. 12 results for "term" when below the cap (unchanged from today).
• No regression in cancellation behavior when the user types quickly.

Cross-refs

• Explorer state contract: URL/DOM/widget-state inventory + search-as-global-filter decision #164 (search-semantics decision — broader context)
• Explorer FTS Track 1b: Honesty fix for query-spec / live mismatch #168 (the comment block above the search query notes the interim recall fix)
• explorer: facet counts — remaining work after #157/#226 #230 (remaining facet-count work)