Harden versioned graph builds and comparison UX

[forhappy]

Summary

• promote a compatible, clean Compass current snapshot directly into immutable versioned history
• canonicalize promoted output so fast and exact builds produce the same realization ID
• reject stale, incomplete, profile-mismatched, or semantically incompatible snapshots, while explicit rebuilds ignore mutable current state
• avoid duplicate history-store validation, reconstruction, and preferred-artifact polling
• load exact parent-specific node, edge, and hyperedge counts in the VS Code history view
• replace the full comparison graph with a focused delta presentation, readable source patches, semantic findings, and an explicit source-only empty state
• keep the VS Code runtime Compass-only; contributor graph refreshes are not imported, bundled, or executed by the extension

Root cause

compass history build repeated graph construction and validation already completed by compass init or compass update, then reconstructed and revalidated stored artifacts more than once. The comparison UI also inferred counts only from presentation graphs, omitted source patches, and rendered the complete graph while comparison mode was active.

User impact

Clean current revisions can enter immutable history without a detached checkout or redundant extraction, while stale, custom-profile, semantic, and explicit-rebuild cases retain exact reconstruction. Version comparisons now distinguish a genuinely unchanged topology from source-only changes and keep exact parent-specific counts visible.

Performance

Measured with a release build against the real fjall repository under /Volumes/Workspace/Github:

Scenario	Before	After	Change
Warmed clean current snapshot, history build HEAD --code-only	2.32s	1.84–1.85s	about 20% faster
Five-version shallow first-parent build	16.17s	11.28s	30.2% faster
Resumed five-version build	—	2.12s	5/5 versions skipped
Repeated validated history build	—	0.47s	cached artifact reuse

The 1.85s confirmation used a fresh history store on fjall (about 16.8K source lines) after the normal CLI capability/version warmup performed by the extension. A newly linked binary's first cold invocation measured 3.74s, so the sub-two-second result applies to the warmed production sequence rather than macOS first-launch overhead. Fast promotion and explicit exact rebuilds produced the same realization ID.

Diff verification

• 13baf811 → 60264f822: exact topology is correctly nodes +0 −0 ~0, edges +0 −0 ~0; the Cargo.toml version bump is retained as a complete source patch
• 2e12d2e7 → 864c18590: exact history diff reports nodes +1 −0 ~4, edges +4 −2 ~0, two source files, and four semantic findings

Known follow-up

The numeric counts, source patches, and semantic evidence are exact. The focused presentation graph can still over-select records when community assignments are renumbered or index-derived viewer edge IDs shift. This draft keeps that limitation explicit for follow-up before claiming fully stable visual identity across every clustered revision.

Validation

• cargo fmt --all -- --check
• git diff --check
• cargo test -p compass-history --lib --tests (64 passed, 1 explicit performance test ignored)
• cargo test -p compass-core --test history_materialize (7 passed)
• cargo test -p compass-cli --lib (63 passed)
• cargo test -p compass-cli --test history_cli (23 passed)
• npm test -w @compass/viewer (16 files / 41 tests)
• npm test -w compass-vscode (18 files / 41 tests)
• viewer and VS Code TypeScript typechecks
• Playwright tests/viewer/history.spec.ts (13 passed)
• production viewer and extension builds
• contributor-only repository graph refresh completed outside the extension runtime