pool: a dropped pool's golden is deleted, and a start sweeps goldens no pool uses

[CMGS]

Closes #333.

Problem

A pool removed from the desired set left its golden on disk forever: goldens/<key hash>/ plus goldens/<key hash>.stamp. Every image roll leaked one multi-GB snapshot per retired key, and a start whose pool set no longer held a key never cleaned it up either.

Change

• Drop: a pool leaves m.pools in two places, applyPools and refillOnce, and both now call dropPool. Under m.mu it removes the stamp and renames the golden to a *.tmp sibling; a goroutine then deletes the renamed directory and logs one line naming the pool.
  • adoptGolden runs under the same lock and needs both the stamp and the directory. So a key that is re-added at once either finds nothing and rebuilds, or never sees the golden at all. It cannot adopt a directory that is being deleted.
• Start: Reconcile already removed goldens/*.tmp. That glob becomes one pass over goldens/ that removes every entry that is not a pooled key's directory or stamp, and logs one line per orphan golden. It covers keys dropped from the config between restarts, goldens left by earlier versions, and a delete that a crash interrupted.
• Docs: sandboxd-api.md (PUT /v1/pools) and deploy.md state that an omitted pool's golden is deleted once the pool is idle, that warm: 0 keeps it, and that a start deletes any golden no pool uses.

Answers to the issue's questions

1. A clone does not depend on its golden after cloning. cocoon copies the disk (reflink or sparse copy) and hard-links the memory file into the VM's own directory, with a symlink only when the two are on different filesystems. Hibernation snapshots, checkpoints and templates are separate exports of the running VM. Deleting a golden is safe for live claims.
2. Keeping a removed pool's golden was not intended; adoption exists for restarts. warm: 0 is the documented way to keep a key registered, so an omitted key is deleted at once, with no grace period.

Not changed

• ReloadConfig and checkImagesOnce. A golden they retire is rebuilt at the same path (exportGolden removes the old directory before the rename), so it is not a leak.
• No size in the log line: the apparent size of a sparse golden overstates what is freed.

Cost and known limits

• Hot path: none. Nothing is added to the claim path or to a refill tick that drops no pool.
• Dropping a pool costs one unlink of the stamp and one rename under m.mu. The delete of the large files runs off the lock.
• At start, orphan goldens are deleted synchronously before the server listens. This happens once per orphan.
• An on-demand claim that resolved the golden just before its pool was dropped can fail its clone. The same can happen today when a rebuild replaces a golden. The claim returns an error and a retry cold-boots.
• The memory file's space is freed only when the last clone that hard-links it is gone.

Verification

• New tests in sandboxd/pool:
  • TestSetPoolsRemovalDeletesTheIdlePoolsGolden: the directory and stamp are gone when SetPools returns, and no *.tmp is left.
  • TestAReaddedPoolRebuildsTheGoldenItsRemovalDeleted: remove then re-add cold-boots a second golden and refills.
  • TestARemovedPoolKeepsItsGoldenUntilItSettles (build, refill): the golden stays while a build or refill is in flight and goes when refillOnce drops the pool.
  • TestSetPoolsWarmZeroKeepsTheGolden: a key kept at warm: 0 keeps its original golden.
  • TestReconcileSweepsGoldensNoPoolUses: an orphan directory, its stamp and a staging directory are removed; the pooled golden is kept and adopted.
• Six mutations of the production code each fail at least one of these tests: stamp not removed, delete without the rename, start sweep limited to *.tmp, warm: 0 also drops, and a plain delete at each of the two call sites.
• go test -race ./... in sandboxd: all packages ok on macOS and on Linux (golang:1.27.1 container, non-root). The new tests pass 300 runs with -race on Linux.
• make go-lint: 0 issues. ×10 (5 modules × linux/darwin), no fmt diff.
• asl -forwarder=false ./...: 0 findings on darwin and linux.

Not verified: no run on hardware. The case worth one check there is a node whose data_dir and cocoon run directory are on different filesystems, where a clone's memory file is a symlink into the golden.