fix(analytics): recompute cached snapshots after the complete startup load #116

Upstream source

Evaluate and adapt Kpa-clawbot/CoreScope#2025: refresh analytics once the entire startup load, including background fill, has terminated.

Current fork evidence

HTTP can bind after the hot chunk. StartAnalyticsRecomputers computes snapshots immediately, then waits roughly five minutes. The RF/topology/channels gate uses LoadComplete, but this becomes true before loadBackgroundChunks fills the retention window. Analytics can therefore serve apparently valid but partial snapshots until the next interval. A lazy distance-index rebuild can create a similar stale snapshot.

Fork-specific adaptation

Enumerate only recomputers that actually exist in this fork. Separate “startup loading terminated” from the existing successful-coverage health meaning of backgroundLoadDone; a failure must wake recomputers without being reported as successful loading.

Acceptance criteria

• A one-shot terminal signal fires exactly once for all startup-load exit paths.
• Every current default-shape analytics recomputer runs once after that signal.
• Manual recomputation runs on each loop and resets its ticker to avoid an immediate duplicate pass.
• Gated endpoints cannot open based on a pass that began before the terminal signal; force-open partial results are replaced promptly.
• Ungated endpoints retain current availability; no new 503 behavior.
• Invalidate dependent caches/throttles before recompute where needed.
• Distance snapshots refresh before the index reports ready.
• Existing background-load health/coverage semantics remain unchanged.

Verification

Deterministically cover success/failure/empty/disabled paths, controlled hot/background loads, recompute ordering, ticker reset, and distance 202 → ready; run full server tests under -race, static checks, and timestamp/snapshot comparisons on an isolated large database copy.

No deploy or live-environment mutation is part of this issue.