sandboxd: add read-only catalog volumes

[CMGS]

Closes #66.

Summary

Read-only shared-dataset volumes. The operator declares a node-local catalog of
disk images; a claim names up to eight of them with optional guest mount paths;
sandboxd takes a compatible warm VM or provisions one, hot-attaches each image
read-only, resolves the device through sysfs, mounts it read-only, persists the
applied entries, and only then returns the claim.

• Catalog and access: volumes entries carry a name, an absolute host path,
  a direct-I/O mode, and an optional tenant access list validated at config load.
  A forbidden name and an unknown name return byte-identical errors, so the
  catalog cannot be enumerated by probing.
• Warm consumption: a volume claim may take an ordinary warm VM — hot-attach
  works on a clone-restored guest. Volume work sits between the warm pop and
  finalize; the volume-less warm path keeps its shape behind an empty-slice
  check. Setup failure destroys the VM and the pool refills normally.
• Device discovery without udev: the attach name appears as
  /sys/block/<dev>/serial, so discovery scans sysfs under a bounded deadline
  rather than waiting on a udev symlink.
• Placement: NodeState.Volumes advertises locally available names.
  VolumeCandidates/VolumeOwners require every requested name, never a union;
  a promoted-template volume claim prefers the advertised template∩volume
  intersection and carries require_promoted on its single no_redirect retry
  so a stale name is never reinterpreted as a cold image.
• Capture and persistence: applied names and mounts persist with the claim;
  hibernate, fork, checkpoint and promote refuse a volume-bearing claim with a
  dedicated sentinel mapped to 409, and the idle sweep skips it. Capture
  decisions read the persisted state, so a catalog or ACL edit cannot make a
  still-attached claim capturable.
• Surfaces: GET /v1/volumes returns the scope-filtered fleet catalog with
  holder counts and no host paths; the claim usage event and SandboxSummary
  carry applied volume names; Go and Python SDKs expose claim options, discovery,
  and the applied entries on the handle.

Write-enabled catalog images are deliberately out of scope: the hardware round
showed correct writable semantics need clean guest-filesystem shutdown across
release, reap, rollback, pre-finalize failure, and restart reconciliation. That
is a separate lifecycle feature, not a flag on this one. Volumes v1 keeps the
existing lockstep deployment boundary; mixed-version serving is unsupported.

Documentation ships with the change: deploy, API, cluster, security, and both
SDK pages.

Validation

Local gates:

• go test -race -count=1 ./... across all five Go modules
• make go-lint on GOOS=linux and GOOS=darwin: 0 issues, no fmt diff
• go vet ./... and asl ./... per module on both platforms
• gofmt -l empty, git diff --check clean
• Python 3.12: ruff check clean, 143 tests passed
• silkd: cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test
• bash -n and shellcheck for scripts/sandboxd-e2e.sh

Bare-metal verification on an AMD Ryzen 9700X node (16 cores, kernel
7.0.0-28-generic), cocoon master-07f1d69, Cloud Hypervisor v54.0.0,
template ghcr.io/cocoonstack/sandbox/rt:24.04@sha256:45944ae3363e:

• the full scripts/sandboxd-e2e.sh with a real ext4 catalog image passed end to
  end, including the existing smoke, reap, and restart re-adoption steps
• two concurrent claims mounted the same image at different paths, read identical
  bytes, and were refused on write with EROFS; both consumed warm VMs, proven
  per claim by the warm-tier counter
• the backing image checksum was unchanged after release
• the volume-less warm claim is unchanged against main: 0.500 ms mean
  (p50 0.5, p90 0.6) before, 0.531 ms mean (p50 0.5, p90 0.6) after, 16
  tier-proven samples per arm, interleaved; the delta is below the harness print
  resolution
• device discovery served roughly 190 real-guest volume claims with no failures

Performance

Measured back-to-back on one host against a provision-only build of the same
feature: 420.9 ms mean per volume claim before, 79.3 ms mean after (5.3x). Two
changes contribute: replacing the udev device wait with the sysfs serial scan —
which alone takes the provision path to 167.5 ms mean — and consuming a warm VM
instead of always provisioning.

Absolute claim latency is load-dependent: a claim landing on the previous
claim's teardown and pool refill ranges 26–150 ms. With the pool settled it is
38.1 ms mean (sd 1.3, n=16, every claim warm-tier proven); the quiet end-to-end
path measures 25.6 ms and 33.3 ms for the two concurrent claims. Per additional
volume in one claim, attach and mount are sequential and cost 60–90 ms.

Review

The branch includes a quality pass over the whole repository — style
walkthroughs, simplification lenses, comment tightening, and a production-LOC
audit whose verified cut-list was applied. That pass is net-negative on
production lines (−35 prod, +14 test) and behavior-preserving; the hardware
round above was re-run at its final commit to confirm no regression.