explorer: facet counts use padded viewport, matching the table (#234)

[rdhyee]

What

Facet-legend counts were computed over the exact viewport (pad 0) in updateCrossFilteredCounts, while every other "in view" surface — the samples-table COUNT (loadCount), the point-mode sample loader, the "samples in view" stat, and the heatmap — pads the viewport by VIEWPORT_PAD_FACTOR (0.3). A sample sitting in that 30% margin was counted by the table but not the facet legend, so the legend read one (or more) low.

Reproduction: /explorer.html?material=…/mineral#v=1&lat=35.0900&lng=32.8900&alt=50000&mode=point → the table says "14 samples match the current filters" but the mineral facet shows 13.

Verified against live data (DuckDB queries at that exact view): the facet query returns 13 at pad 0 and 14 at pad 0.3 (== the table). Exactly one mineral sample lives in the pad margin.

Fix

One line in updateCrossFilteredCounts — align the facet-count bbox to the shared contract:

- const bboxSQL = isGlobal ? null : viewerBboxSQL('l.latitude', 'l.longitude', 0);
+ const bboxSQL = isGlobal ? null : viewerBboxSQL('l.latitude', 'l.longitude', VIEWPORT_PAD_FACTOR);

The heatmap hit the identical mismatch earlier and was moved to the padded contract in the #241 follow-up; this aligns the last stray surface.

The durable fix — one shared "in view" bbox source so these surfaces can't drift apart again — is noted as architectural follow-up on #234.

Tests (tests/playwright/facet-viewport.spec.js)

• New coherence regression: active-material legend count == table "N match" count at the repro view (backreference assertion — 14/14 passes, 13/14 fails).
• Hardened flyToAndSettle: the padded (slower) facet query reliably exposed a pre-existing race — the helper waited only for .recomputing to clear, which can be a transient before the new counts apply. It now keys on the full recompute cycle (.recomputing appear → clear) plus a two-consecutive-equal-reads stability gate, so it's correct even for moves that leave counts unchanged. This also confirms there is no real product stale-overwrite race — the restore settles correctly on global.
• Full B1 suite green 2× each (10/10).

Provenance

Claude; empirically verified (DuckDB 13/14 + Playwright); Codex 2-round review (resolved an unchanged-counts hang in the test helper). Deployed to the rdhyee fork staging and verified live (mineral legend now reads 14, matching the table).

🤖 Generated with Claude Code

[rdhyee]

Rebased onto upstream/main (was 41 commits behind). Finding: this PR's actual fix is already shipped. The conflict in explorer.qmd was at the exact viewerBboxSQL('l.latitude', 'l.longitude', ...) line this PR changes from pad 0 to VIEWPORT_PAD_FACTOR — upstream/main already reads VIEWPORT_PAD_FACTOR there, shipped independently via #251 ("explorer: search as a real global filter (#234 step 4)", May 31) a few days after this branch forked (May 28). After resolving in favor of upstream's version, explorer.qmd is now byte-identical to upstream/main — confirmed with git diff upstream/main -- explorer.qmd (empty).

What's left and still valuable: the new Playwright regression test in tests/playwright/facet-viewport.spec.js ("coherence: active-material legend count == table 'N match' count") plus the hardened flyToAndSettle helper (keys on the full .recomputing appear→clear cycle + a two-consecutive-equal-reads stability gate, replacing a flaky fixed-timeout wait). Those survived the rebase as the only remaining diff vs upstream/main (41 insertions / 5 deletions, test file only) and are worth keeping as a regression guard for the now-shipped fix.

Tests: npm run test:unit — 13/13 pass. The Playwright spec needs a live dev server with the real explorer page (Cesium globe + live R2 parquet data) — attempted it against a local quarto preview, but #cesiumContainer never became visible within the 30s timeout in this sandbox (no GPU/WebGL + likely network constraints), so I couldn't execute it end-to-end here. Recommend running it in CI or a normal dev machine before merge.

Pushed the rebased branch. Not auto-marking ready for review — flagging the already-shipped finding for you to decide whether to close this PR (superseded by #251) or merge it anyway for the regression test.

[rdhyee]

🤖 rbotyee (Claude, operated by @rdhyee) — Raymond's intent: closing-week PR sweep — merge if a fresh Codex review still says LGTM against today's main. What I did: ran that review; verdict below; merging.

Codex re-review vs current main (2026-07-17): LGTM, 0 findings

Notable: the runtime padding fix this PR was written for has since landed on main independently — updateCrossFilteredCounts() already uses VIEWPORT_PAD_FACTOR, and all count-bearing "in view" surfaces are consistently padded (verified against the post-#300 / post-#335 code). What this PR still contributes is the Playwright regression spec (5 facet-viewport tests), which Codex verified still matches today's moveStart/moveEnd event contract. Merging for the test coverage.