perf(snapshot): serialize once in writeSnapshotDual, byte-copy to the cache

[justrach]

Round-2 item 3 (snapshot write-path survey — the write path had never had a perf pass; load got 3× in #524).

What

writeSnapshotDual ran the full writeSnapshot serialization twice — project-root snapshot, then ~/.codedb/projects/<hash>/: two shared-lock acquisitions, two per-file content-hash passes, two tree/outline serializations, and — after releaseContents() (the normal post-scan server state, #519) — two whole-repo disk reads. A finished snapshot is a plain file: serialize once, then byte-copy to the cache path with the same tmp-random-suffix + rename contract.

writeProjectCacheSnapshot keeps full-serialization behavior for its standalone callers (bootstrap CLI fallback, tests).

Correctness

• Same write order (primary first), same swallowed-error semantics for the cache copy, same atomic-rename crash-safety, no format change.
• Bonus guarantee: the two copies are now byte-identical — verified by sha256 after a live run — where two serializations could diverge between lock acquisitions.
• zig build test: 23/23 steps, 869/873 (4 platform skips). e2e: 20/20.

Numbers

• Synthetic 2,000-file / 92MB corpus, codedb <root> snapshot, 3 runs each: 0.78s → 0.72s median — the eliminated second serialization (~60ms here) scales with snapshot size, and grows further on released-contents servers where it also paid the whole-repo re-read.
• This repo (small snapshot): no measurable wall change (0.06s both) — the win is size-proportional, as expected.

🤖 Generated with Claude Code

[justrach]

Superseded by #652 (landed while this was in review — same change, convergent implementations from the same write-path survey). Numbers from this PR's validation transfer: 92MB corpus snapshot 0.78s → 0.72s median, cache copy byte-identical (sha256-verified).