fix(core): defer snapshot repository discovery

[kitlangton]

Summary

• defer Snapshot Git repository discovery until the first snapshot operation
• memoize the discovered repository/worktree state so later captures and comparisons retain existing behavior
• avoid making every cold location graph pay snapshot setup during daemon replacement

Bottleneck

Per-node acquisition timing identified Snapshot setup as the dominant location-readiness cost during concurrent cold starts:

Location	Total location boot	Snapshot acquisition
opencode	803 ms	552 ms
life-hub	2,477 ms	2,077 ms
browser-control	3,143 ms	2,301 ms
openeval	3,144 ms	2,270 ms
experiments	3,214 ms	1,706 ms

Snapshot eagerly called git.repo.discover() and canonicalized the worktree while the location layer was acquired. Most reconnected locations need config/session data immediately but do not perform a snapshot operation.

flowchart LR
subgraph Before
L1[Acquire location] --> G1[Discover Git repository]
G1 --> R1[Location ready]
end
subgraph After
L2[Acquire location] --> R2[Location ready]
R2 --> C[First snapshot operation]
C --> G2[Discover and memoize Git repository]
end

Loading

Benchmark

An isolated Bun harness launched a fresh local server for each trial with temporary database/data/state paths, waited for authenticated health, then measured /api/location for one real repository followed by four concurrent cold repositories. The active managed daemon was never contacted or restarted.

Two seven-run baseline series bracketed the candidate run to control for cache warming:

Metric (median)	Baseline before	Lazy Snapshot	Baseline after	Candidate vs nearest baseline
Single cold location	426 ms	137 ms	496 ms	-68% to -72%
Slowest concurrent location	1,656 ms	919 ms	1,987 ms	-44% to -54%

The benchmark used one warmup plus five preliminary measurements, then two warmups plus seven measured A/B runs. Raw spreads were noisy, but both bracketing baselines remained materially slower than every candidate median.

Semantics

The first call to capture, files, diff, preview, restore, or checkout resolves the same repository/worktree state as before. Effect.cached shares one Location-scope-owned initialization fiber across concurrent and subsequent operations. Acquiring that shared fiber is uninterruptible, while waiting for its result remains interruptible, so cancelling the first caller neither blocks cancellation nor memoizes an interrupted result.

When snapshots are disabled, capture can now return without performing Git discovery at all.

Follow-up

This removes the largest measured node from the reconnect herd in #36285. Remaining measured costs are concurrent project resolution, config discovery, and eager Shell output setup; they should be optimized in separate benchmarked changes.

Verification

• bun typecheck from packages/core: passed
• bun run test test/snapshot.test.ts test/session-runner.test.ts from packages/core: 121 passed
• full Core suite: 1268 passed and 6 skipped; existing filesystem watcher timeouts reproduce unchanged on the untouched baseline worktree

[kitlangton]

Independent verification confirmed the source cause and benchmark direction.

• Baseline Snapshot.boot eagerly runs Git discovery, which performs filesystem ascent and three git rev-parse calls.
• Candidate 0d3915f5 moves that work behind lazy cached state; instrumented Snapshot acquisition drops from 552-2,301 ms to 0 ms.
• Reconstructed server-log medians were approximately 423 / 1,646 ms (baseline A), 134 / 707 ms (candidate), and 463 / 1,954 ms (baseline B) for single / slowest-concurrent location boot.

Caveats: trial blocks were sequential rather than interleaved, real user plugins/MCP/config were active, and the change defers rather than removes discovery, so the first actual snapshot operation pays it. The post-candidate baseline returning to the original range makes the location-readiness win credible despite those confounders.