Skip fresh auto optimized archive rebuilds

[andrewtdiz]

Summary

• skip the auto-optimized runtime/stdlib Cargo invocation when hash-keyed archives are already fresh
• write and require a profile stamp so old archives or different feature profiles stay conservative
• add optimized-lib freshness/no-Cargo tests plus object-cache verification coverage

Investigation

The remaining small native source-change latency was not object-cache churn. In the dep-wide-100k shape, a one-module edit should invalidate one generated TS module, reuse the other native objects, and relink. The expensive extra work was in build_optimized_libs: every build-cache miss still spawned cargo build --release -p perry-runtime -p perry-stdlib ... for the hash-keyed auto runtime/stdlib target, even when the static archives were already present and source inputs were unchanged.

This PR keeps the first run conservative. After a successful auto build writes .perry-auto-build.stamp, the next build-cache-miss source edit can reuse fresh archives without spawning Cargo. The freshness check requires:

• matching auto-profile stamp (target, triple, feature set, shared-tokio crates)
• existing runtime and stdlib archives
• archives newer than Cargo.toml, Cargo.lock, perry-runtime, perry-stdlib, and any shared-tokio wrapper source dirs
• no LLVM bitcode request

Verification

• cargo fmt --all -- --check passed
• cargo test -p perry build_optimized_libs_reuses_fresh_auto_archives_without_cargo -- --nocapture passed: 1 passed, 0 failed
• cargo test -p perry optimized_libs -- --nocapture passed: 12 passed, 0 failed
• cargo test -p perry object_cache_tests -- --nocapture passed: 27 passed, 0 failed
• cargo build -p perry --release passed: finished release profile in 2m 03s
• target/release/perry --version -> perry 0.5.1154

Scaled native proof

After the real host auto archives existed, the first patched compile stamped them. Then I changed one source module and reran compile with PATH=/usr/bin:/bin:/usr/sbin:/sbin, where cargo is unavailable but cc/link tools are still available. The second build succeeded, which proves the production path did not spawn Cargo.

Command shape:

/usr/bin/time -lp target/release/perry compile --format json work/scaled-native/src/main.ts -o work/scaled-native/app
# edit gen_0.ts
PATH=/usr/bin:/bin:/usr/sbin:/sbin /usr/bin/time -lp target/release/perry compile --format json work/scaled-native/src/main.ts -o work/scaled-native/app

Results:

• first compile: 1.28s real, output 42, checksum 084c799cd551dd1d8d5c5f9a5d593b2e931f5e36122ee5c793c1d08a19839cc0
• second source edit: 0.40s real, output 43, checksum 0e55092af0746630c98d1b2e0d960617c33f8ea7b55739fd18cb7cd5342a28ca
• second counters: native_modules=3, build_cache.hit=false (miss_reason=env from the deliberate PATH change), codegen_cache.hits=2, misses=1, stores=1, object_cache_paths_reused=2, object_cache_paths_stored=1, link_cache.linked=true, object_fingerprints_used=3, object_files_hashed=0, external_inputs_hashed=1
• stamp written: target/perry-auto-8981e03852ab7578/.perry-auto-build.stamp with key=crypto|true|host|wasm=false and features=perry-runtime/full,perry-stdlib/crypto

100k benchmark status

Baseline from the latest report: dep-wide-100k native small_change Rust 2.26s vs Perry 2.98s median; no-op already fixed at Rust 0.36s vs Perry 0.12s.

I generated the dep-wide-100k repro and attempted the full native small-change run, but the run was initially consumed by first-time auto runtime/stdlib archive seeding in target/perry-auto-8981e03852ab7578. Per the lane supervisor guidance, I stopped waiting on that path and switched to the focused scaled proof above. The full dep-wide-100k after wall-clock should be rerun from a seeded archive state.

[proggeramlug]

Heads-up after rebasing this onto current main: cargo-test fails in this PR's own area — 4 commands::compile::optimized_libs tests (build_optimized_libs_reuses_fresh_auto_archives_without_cargo, forced_well_known_env_extends_iteration_set, no_auto_builds_missing_well_known_archive_from_workspace_source, no_auto_still_resolves_prebuilt_well_known_archives). Most likely a semantic conflict with #5013 (auto-optimize runtime cache is now version-keyed, merged 2026-06-11), which changed the archive resolution this PR's reuse logic asserts against. Main's other CI reds are fixed as of #5033, so these 4 are the only blockers — needs a rework against the version-keyed cache.