Phase 6 v2: build morton-hive awareness on healpix-geo (after d70-t/gridlook#192), not @hcsmap/healpix

[espg]

🤖 from Claude

Tracks the Phase-6 dependency decision from the #1 plan: upstream is replacing gridlook's healpix backend, and Phase 6 v2 ("moczarr-lite" morton-hive awareness) should be built on the replacement, not the library being deleted.

What changed upstream

d70-t/gridlook#192 (keewis, 2026-07-19) replaces @hcsmap/healpix with healpix-geo (wasm bindings over CDS's Rust healpix) in the healpix view. It brings exactly what Phase 6 v2 planned to hand-roll:

• cell ids beyond 2^53 — the "BigInt for u64 words" requirement (mortie spec §1 note: JS number covers NESTED only through order 24);
• multiple indexing schemes — nested / ring / zuniq (zuniq is the CDS cousin of mortie's packed word: left-aligned path bits + depth marker, so raw sorts are curve-ordered and descendant ranges are contiguous — the same two properties the mortie word guarantees by spec);
• ellipsoidal boundaries (see caveat below — we must not use these).

It's paired with d70-t/gridlook#191 (webworker rendering; healpix deliberately left to d70-t#192), so the post-merge shape of upstream's healpix path is worker-side wasm — also the right home for Phase-6 BigInt hive-path arithmetic.

Decisions this issue records

1. Sequence Phase 6 v2 after support ellipsoidal healpix and more indexing schemes through healpix-geo d70-t/gridlook#192 lands (or develop against keewis's ellipsoid branch if it stalls). Building on @hcsmap/healpix now would target a library upstream is actively removing. Phases 1–3 (vector layers) are unaffected — support ellipsoidal healpix and more indexing schemes through healpix-geo d70-t/gridlook#192's changes (Healpix.vue, GlobeTypes.ts, dep swap) are disjoint from the geojson/layer-stack files; only package.json/vite.config.ts need trivial merge care.
2. The Phase-6 shim shrinks to: mortie packed word → (order, nested ipix) (a few bit ops per mortie spec §1: 4-bit base prefix with +1 shift, 27×2-bit left-aligned body, 6-bit suffix carrying order/kind) → healpix-geo for geometry. Golden vectors ported from moczarr (-5112333, hive path, ranges envelope) pin TS↔Python parity, plus at least one boundary golden (word → expected corner lat/lons).
3. Pin sphere mode, not ellipsoidal. Verified against the mortie 1.0 spec and the Rust kernel: mortie hashes raw geodetic lat/lon degrees into the spherical HEALPix mapping (no geodetic→authalic conversion; spec §3 pins the sphere at R = 6371.0088 km). Rendering mortie cells through healpix-geo's ellipsoidal (WGS84/authalic) mode would shift boundaries by up to ~20 km at mid-latitudes. The shim must select the sphere and a golden boundary test must pin it.
4. Keep the fork synced through Feat/webworker d70-t/gridlook#191/support ellipsoidal healpix and more indexing schemes through healpix-geo d70-t/gridlook#192 — the healpix path is churning now, and Phase-6 work based on a stale base would be dead on arrival as an upstream offer.

Watch items

• keewis flags support ellipsoidal healpix and more indexing schemes through healpix-geo d70-t/gridlook#192 as slow (TS↔wasm boundary overhead, per-call ellipsoid parsing). Irrelevant at shardmap feature counts (10^2–10^4), potentially noticeable for high-order datacube views — benchmark before Phase 6 acceptance.
• If upstream asks for morton/zuniq scheme support directly in gridlook, the shim's word→(order, nested) mapping is the piece to offer (same per-piece upstream policy as Plan: shard-vector + output-grid globe viewer, packaged for JupyterHub (cryocloud) #1).

Refs: #1 (plan, Phase 6), d70-t#191, d70-t#192, mortie spec §1/§3, moczarr golden vectors.