Snapshot build metadata once per sweep instead of recomputing it per point

[emircbngl]

Summary

run sweep recomputes identical build/environment metadata for every successful point. In a small 11-point 1D sweep, metadata collection took far longer than all eleven solves and spawned 22 Git subprocesses.

A command-scoped build snapshot prototype reduced the warm sweep median from 299.49 ms to 25.90 ms (11.56x) while retaining one ordinary artifact per point.

Measured on public main at 5100ab00cb8b2aa5d43682ab0e9b871bee8f7ac1 on an Apple-silicon CPU.

Profile

For an 11-point 1D sweep from 0.20 V through 0.40 V:

_run_sweep                         0.470 s
artifact.write_run                 0.325 s
artifact.environment               0.302 s
artifact.git_commit                0.275 s
all 11 solver calls combined       0.018 s

artifact.write_run() currently performs this for every point:

env = environment()
build = code_id(env)

environment() hashes the same imported package source and calls both git rev-parse HEAD and git status --porcelain -- src. Eleven successful points therefore run the same source scan eleven times and spawn 22 Git subprocesses.

Benchmark

Seven warm samples, medians:

current per-point metadata:  299.494 ms
one snapshot per sweep:       25.903 ms
speedup:                      11.56x

Suggested direction

Compute an immutable environment/build snapshot once at the start of _run_sweep and pass it to every write_run() call. Keep write_run()'s current self-computing default for standalone callers so its API remains safe outside a command-scoped batch.

This is preferable to an unbounded module-global cache: a later independent command must see source or environment changes.

Semantic decision to make explicit

A long-running sweep could overlap with a source/worktree change. Define whether all points belong to the build observed when the command started, or whether such a change should abort the sweep. Whichever policy is chosen, every artifact in one successful sweep should carry a deliberate, tested build contract rather than inheriting timing from repeated subprocess calls.

Regression coverage

1. Assert environment/source/Git discovery runs once per sweep, not once per point.
2. Assert every point records the same environment and code_id snapshot.
3. Assert a standalone write_run() still computes a fresh snapshot by default.
4. Keep artifact contents, checksums, run IDs, and compare semantics unchanged.

[emircbngl]

Fixed in 04df808.

Reproduced first: an 11-point 1D sweep spent 0.295 s of 0.917 s in
environment(), spawning 22 git subprocesses, while all eleven solves
together took 0.018 s — the metadata cost ~16x the physics.

After: 2 subprocesses, 0.253 s total.

write_run() takes an optional build_snapshot; _run_sweep computes one at
the start and passes it to every point. The default stays self-computing, and
it is a parameter rather than a module cache for the reason the issue gives —
a later independent command must see source changes.

The semantic decision, made explicit: every point of one sweep belongs to
the build observed when the sweep started. A mid-sweep source change no
longer silently splits a batch across two builds, which is what happened
before, since each point ran git status independently. It does not abort the
sweep; the snapshot is recorded in every artifact so the contract is auditable.

All four regression items from the issue are covered:

1. discovery runs once per sweep — asserted by counting subprocesses, not
   by timing. A timing assertion would be the machine-fitted mistake this
   review cycle has already caught four times; the count is the invariant.
2. every point records the same environment and code_id.
3. a standalone write_run() still computes a fresh snapshot, and an explicit
   snapshot is honoured rather than ignored (checked with a synthetic pinned
   version that changes the code_id).
4. artifact contents, checksums, run ids and compare semantics unchanged —
   the existing suite covers these and is green.

Push CI 7/7 and the cross-oracle job are green on this exact SHA.