[CMGS]

Fixes from a whole-repo correctness read of the warm pool, the checkpoint stores and volume teardown, plus one promote-path speedup. Stacked on #420.

Fixes

• Dead warm VM handed out. A warm VM whose VMM exited stayed in the pool: /v1/info and the mesh counted it, refill never replaced it, and a claim got it with 200 and then 502s. The poll, the daemon snapshot and exit events now evict a warm VM reported present and not running, after one Inspect confirms it, destroy it and refill. A node with warm VMs and no claims still polls.
• no_balloon ignored after a restart. The golden stamp did not cover it, so flipping it adopted the old golden. It is stamped only when set, so default goldens stay adoptable.
• A guest's own disk-full parked every pool. A warmup that printed no space left on device matched the node capacity signature. A guest exit error no longer carries one.
• Shared checkpoint_dir: a restart deleted a peer's in-progress staging. The startup sweep now removes only staging older than the generation grace.
• dir commit pointer not durable. meta.json is fsynced and its directory synced before the archive path drops the VM.
• S3 fetch cache never reclaimed. A record deleted by another node, or recreated in cache by a canceled fetch's detached flight, stayed on disk until restart. The generation sweep drops a cache unused within the grace whose record is gone from the bucket. The bucket is never touched.
• A delete that succeeds now vetoes an in-flight heal, so a deleted checkpoint cannot come back after a 204.
• Volume timeouts answered 500. Attach, setup and detach failures carry the context error, so the documented 504 and 408 hold.
• Volume unmounts capped at 2 s. A flush longer than 2 s lost its unsynced writes while release succeeded, and live removal failed at 2 s against a documented 30 s. Each unmount now runs on its volume's 30 s budget; once one unmount runs out, a release skips the rest (their markers stay), so a wedged guest costs at most 30 + 2 s.

Performance

• Promote on the dir store reads holes. A chunk with no data takes the precomputed zero sum instead of a 16 MiB read; digests are unchanged and still match the s3 backend. 10 GiB disk with 200 MiB of data, interleaved 8 rounds, p50: 1.149 s -> 0.099 s (macOS APFS), 1.142 s -> 0.133 s (Linux overlay).

Cost

Nothing on the claim path. One vm list per minute on a node holding warm VMs and no claims; one file and one dir fsync per dir publish; one GET per idle cached id per sweep.

Tests

Each fix has a regression test that fails against the old code or a mutant of the fix. go test -race on pool, engine and store; golangci-lint and asl clean on darwin and linux.

Update

Later commits on this branch:

• Refill kick after a fresh golden (regression from pool: let a golden's guest finish starting before its snapshot #415). The ready path neither refilled nor kicked, so warm pools filled one 2 s tick late whenever the golden finished after that tick. Interleaved on hardware, with and without the kick: port-e2e 6.0 -> 4.0 s, archive-e2e 46 -> 41 s; against main on another cocoon version, egress lane 9.1 -> 7.1 s.
• A golden whose clones keep failing is retired and rebuilt. The stamp cannot see a Cloud Hypervisor rollback, and a golden built on v55 and restored on v54 failed every clone with every claim answering 500, forever. After 8 clones in a row fail, whether a refill's or a claim's, the golden's stamp is removed and it is rebuilt, at most once per 30 s. A node-capacity failure, a canceled claim, a failed probe and a promoted template's clone do not count; the directory stays for a claim still cloning it. Hardware: warm 2 and warm 0 pools both recover by themselves, claims answer 500 until the 8th failure, cold-boot during the rebuild, then clone.
• A warm VM claimed during its eviction goes to recovery instead of waiting for the next poll. With cocoond_socket a dead warm VM is evicted about 0.15 s after its VMM exits, without it up to 10 s; a warm claim stays unprobed, so one landing inside that window answers 200, then 502 until vmm_restart acts. docs/deploy.md states this.
• The hourly sweep covers the template view on a shared store, which keeps its own fetch cache.
• The periodic sweep removes aged staging, so a crash leftover on a local root does not wait for a later restart.
• The port reader starts at 4 KiB and grows on the first frame that needs it. Preview, 1 KiB response: 93 -> 64 us p50, 444 -> 89 KB allocated per request; 4 MiB response: 0.15-1% slower at p50, within its run-to-run spread.
• The liveness poll no longer skips a node with no claims and no warm VMs.

Merge this before #428: the golden paragraph there describes this branch.