pool: a removed pool's golden stays on disk #184

A pool removed through PUT /v1/pools (or dropped from the config file before a restart) leaves its golden behind: SetPools deletes the pool entry (sandboxd/pool/setpools.go), nothing removes <data_dir>/goldens/<hash> and its .cafp/.nic/.warmup sidecars, and Reconcile sweeps only *.tmp staging dirs and stale snapshots (sandboxd/pool/reconcile.go). A golden is a full exported VM (memory image plus disk), so each retired pool or template revision leaves gigabytes on disk until an operator finds them by hand.

The leftover is not useless while the key may come back: adoptGolden re-adopts it on the next PUT of the same key and saves a rebuild, which argues against deleting at removal time.

Fix shape: at startup, after the persisted pools are adopted and their goldens resolved, remove any goldens/<hash> whose hash matches no live pool (nothing can be cloning from it that early), or age them out with a generous grace (days) if a removed key is expected to return. One unit test with a stray golden dir plus the existing TestReconcileSweepsGoldenTmpDirs shape.