refactor(engine): point-source slot wiring registry (Phase 4)

[rulkens]

Summary

• New pointSourceRegistry.ts declares the 5 point-source slots (SDSS, 2MRS, GLADE, Famous, Synthetic) as a typed POINT_SOURCE_REGISTRY table plus a wirePointSourceSlot(state, cfg, deps) helper.
• engine.ts's bootstrap IIFE now loops over the registry instead of an inline 60-line slot-construction block:

  for (const cfg of POINT_SOURCE_REGISTRY) {
    wirePointSourceSlot(state, cfg, { cb });
  }

• Sidecar slots (filaments, famous-meta, pgc-aliases) stay bespoke — their shape diverges materially from the point-source uniform contract (different fetchers, different commit targets, different lifecycle).
• engine.ts -73 lines (1953 → 1880). Net diff: +518/-87 (the registry module + 7 unit tests are larger than the inline loop they replace, but they're tested and reused).

Why a registry

• The pre-Phase-4 loop already iterated five sources but mixed three concerns (per-source variance, slot construction plumbing, engine-state side effects) in one block. Reifying the variance as a declarative table lets future surveys edit one row instead of tracing through a multi-arm conditional in the middle of a 1100-line bootstrap IIFE.
• Behaviour is byte-for-byte identical. Slot names, commit body, onCloudReady echo, requestRender wake, and storage in state.assetSlots.points all match the pre-registry loop.

What stays the same

• The boot-time allArrivalsPromise and the synthetic-fallback gate look up slots by Source from state.assetSlots.points — registry preserves those keys.
• The post-loop allSlots aggregation (used by createLoadProgressEmitter) iterates state.assetSlots.points unchanged.
• setTier's per-source reload loop (lines ~1856) still iterates [Source.SDSS, Source.TwoMRS, Source.Glade, Source.Famous] and calls state.assetSlots.points.get(source)?.load(...).

Test plan

• pointSourceRegistry.test.ts (7 tests) covers: registry declares 5 sources in enum order; real surveys share one fetcher and Synthetic uses a distinct one; helper builds + stores slot keyed by Source; multiple sources produce independent slots; subscriber fires onCloudReady + requestRender on ready; commit uploads to renderer + writes state.sources.clouds; commit no-ops when state.gpu.renderer is null.
• npm run typecheck clean (src + tools).
• full suite green (925 tests, +7 from Phase 3's 918).
• manual smoke: load fresh, every survey arrives in the dev panel; tier switch triggers the right per-source reloads; synthetic fallback still kicks in if all real surveys are emptied.

Survey table (Task 4.1)

Source	Fetcher	Initial request	Commit	Subscribe behaviour
Source.SDSS	pointCloudFetcher	{ source, tier: state.sources.tier } (from later block)	upload to state.gpu.renderer + log + write state.sources.clouds	on ready: cb.onCloudReady?.(source, count) + requestRender()
Source.TwoMRS	pointCloudFetcher	same	same	same
Source.Glade	pointCloudFetcher	same	same	same
Source.Famous	pointCloudFetcher	same	same	same
Source.Synthetic	syntheticPointFetcher	same shape (tier ignored by fetcher)	same	same

All five share the exact same skeleton; the only axis of variance was the fetcher. The registry rephrases the ternary as one row per source.

Sidecar slots NOT in the registry:

• filaments — different fetcher (filamentFetcher), different payload (FilamentCloud), different renderer target (FilamentRenderer.upload), one-shot lifecycle (no tier reload). Absorbing it would require parameterising payload, commit target, and lifecycle on every registry row.
• famous-meta — pure metadata, no commit step, custom error handling that maps kind: 'error' → "feature off" by writing empty meta/xrefs.
• pgc-aliases — lazy-loaded via loadPgcAliases() shim, not at boot. Wrong lifecycle for a boot-time registry loop.

Spec: docs/superpowers/specs/2026-05-08-engine-internal-restructure-design.md (#3)
Plan: docs/superpowers/plans/2026-05-08-engine-internal-restructure.md (Phase 4)

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	skymap	4ebb8ee	Commit Preview URL Branch Preview URL	May 08 2026, 12:34 AM