Explorer v2 behind ?v=2 (lite parquet, lazy description, no RANDOM, lazy Cesium)

[rdhyee]

Second of two PRs for the Explorer rethink. v1 untouched; opt-in v2 via ?v=2.

Four moves (each gated on version):

1. Lite parquet as primary — samples_map_lite.parquet (60 MB) instead of wide.parquet (278 MB).
2. No ORDER BY RANDOM() — bare LIMIT is ~20× faster on columnar parquet; accept row-order bias for now.
3. Lazy description fetch — query wide.parquet for just one pid when a sample is clicked.
4. Lazy Cesium mount — don't construct the viewer until viewMode === 'globe'.

v1 baseline captured in PR #124's panel:

• nav → count ready: 28.9 s
• nav → samples ready: 16.5 s
• sample data query: 14.1 s

v2 expected to slash these by a factor of 4-10. Measured via the same ?perf=1 panel — will post numbers after merge.

🤖 Generated with Claude Code

[rdhyee]

v2 results (3 cold runs on production, headless Chrome, cache disabled)

Metric	v1	v2	Δ
first-paint	512 ms	400 ms	−22%
DuckDB init + views	1.59 s	1.35 s	−15%
facet summaries query	93 ms	66 ms	−29%
sample data query	14.1 s	8.1 s	−42%
count query	26.5 s	21.1 s	−20%
nav → samples ready	16.5 s	10.3 s	−38%
nav → count ready	28.9 s	23.3 s	−19%

Meaningful — sample data query cut nearly in half, overall time-to-usable dropped ~6 seconds. But less than expected (we hoped for 4–10×, got ~2×).

Why it's not more

v2 still makes 113 range requests to the lite parquet on initial load. Switching file size 278 MB → 60 MB only helped so much because the bottleneck isn't total bytes — it's DuckDB-WASM's many small range requests + the facet subquery join against sample_facets_v2 (63 MB). The four moves were architecturally right but hit a deeper wall.

Where the real wins likely are next

1. Skip the COUNT query entirely for unfiltered/simple cases — use pre-computed counts from facet_summaries.parquet (already loaded, 2 KB) when no facets are selected. Could drop "nav → count ready" from 23 s to ~2 s. Lowest-hanging fruit.
2. Port the cross-filter pre-aggregation pattern from Interactive Explorer — for common filter combinations, answer from the 6 KB cache instead of querying lite at all.
3. ATTACH a .duckdb file — instead of read_parquet with many range requests, use DuckDB's native file format (one bigger fetch, fewer round-trips). Requires a build-step change to produce the file in the PQG pipeline.

Status

Paused here. v2 is live behind ?v=2. Users who want it can opt in; default is still v1. Next step is a separate design decision (options 1–3 above) before more code.