Fix the three refill-path stalls that cap a large warm-pool fill

[doge-rgb]

A 0→50000 fill across 20 nodes reached 97% in seconds, then crawled, and a node
would sometimes settle short of target and stay there. Three independent causes,
all on the refill path.

A warm refill probed readiness with the claim deadline (15s). A claim
deserves that patience — a caller is blocked on it. A refill has nobody waiting,
and it holds a slot in the pool's target accounting for its whole probe; a clone
answers in about a second even on a saturated node, so one silent for longer is
an outlier to replace, not wait on. Warm refills now use warmProbeTimeout
(5s); claims and forks keep the generous deadline.

A remove's word was taken at face value. cocoon vm rm contends with every
concurrent create on the node's metadata store, and the engine SIGKILLs it at
its per-command bound — which can kill it partway through, with the guest still
running, or after the work was actually done. Both directions used to be
misread: a remove that failed loudly but had in fact completed left its caller
retrying (or holding an egress lock) forever; treating a killed one as done
would silently leak running VMs from all accounting (measured once at ~570
orphans on a node). A remove that reports failure is now verified against the
engine's own list — really gone releases the slot, still listed stays accounted
for the reaper to retry — and every remove path (refill cleanup, reap, archive,
release, rollback) goes through the same verified helper.

A node-wide capacity failure was retried at full concurrency forever. A
Linux bridge returns EXFULL for its 1025th port; BR_MAX_PORTS is a
compile-time constant, so the condition clears only when VMs go away. Every
retry still forked the engine, built a netns and ran the CNI plugins before
failing, each taking the global rtnl lock — the retries cost more than the work
they replaced, wrote twenty thousand log lines an hour, and drove load past 180
on an idle-CPU box. The engine now classifies these failures at the subprocess
boundary (engine.CapacitySignature: exchange full, no space left on device), and one classified failure parks all VM spawning — refills and golden
builds — node-wide for capacityBackoff (30s), logs once per episode, and
publishes at_capacity/at_capacity_reason through /v1/info so a placer
reads a short warm count as "full" rather than "still filling". Capacity
failures do not count toward any pool's own failure streak: that backoff (#55)
stays the per-pool fallback for failures the node cannot classify.

Measured after: 10000 warm across 20 nodes, 9000 new ready in 6.7s, no node
below 237/s.

Tests

• a failed remove whose VM the engine still lists is not reported gone; one
  whose VM is really absent is, and the ordinary path is unchanged
• one capacity-classified failure parks the node and publishes the gauge; later
  ticks spawn nothing until the backoff expires; a park is not a latch
• only node-wide signatures classify — ordinary boot failures and missing
  goldens do not
• Back a warm pool off after an unbroken run of failed refills #55's streak test now uses an unclassifiable error, since exchange full
  parks the node after a single failure before a streak can form

go test ./... green (including -race on the pool package); golangci-lint
(pinned v2.12.2) clean on GOOS=linux and GOOS=darwin.