[CMGS]

Cleanup of volume compatibility code. Do not merge until @minatoaquaMK2 confirms there is no compatibility need below.

In this PR: drop volume holds for archived claims

#382 made archived claims count their volumes (adoption, restart, ownership transfer, reap) to cover one case: a live read-only attach that finishes while an older replica export runs, so the published replica row carries the volume. That race existed from v0.1.17 to v0.1.19. #383 refuses that publication (replicate and putRow recheck holds), so no new row can carry volumes, and no deployment we know of ran replication together with live volumes on those versions.

• Removed: the adoptVolumes calls in adoptArchived and Reconcile, the archived release in forgetClaim, and the reap-purge release.
• Removed tests: the legacy replica fixture and the three tests built on it.
• Net: prod −10, test −215.

If a legacy volume-bearing replica row still exists somewhere, the adopted archived claim would not hold its volume: unregister could retire that name, and a writer could be admitted beside it. The archived claim has no VM, and wake does not reattach volumes.

Compatibility layers we plan to remove in a later release

None of these change in this PR. They are listed here so the exit is agreed in one place.

1. Claim-wide volumes_attach_only (server ClaimRequest, Go WithVolumesAttachOnly, Python mount=False). The per-entry attach_only field replaces it. Released SDKs send the claim-wide flag, and claims decode leniently, so removing it server-side without a coordinated SDK release would make old clients mount volumes they asked to only attach. Plan: SDKs expand it onto the entries client-side, then the server field goes in a release that requires matching SDKs.
2. Claims journal migration that derives attach_only from an empty mount when loading old claims.json rows. Removing it needs every node to have rewritten its journal with the field (one commit after upgrade covers live claims).
3. The per-call cocoon v0.7.2 gate for live volume changes (CheckLiveVolumeSupport). The startup floor is still v0.6.9, and some nodes run cocoon below v0.7.2. Plan: raise the startup floor to v0.7.2 once every node runs it, then drop the per-call gate.

@minatoaquaMK2: do your deployments or the controller branch depend on any of these (a legacy volume-bearing replica row, the claim-wide flag, journals written before #383, or cocoon below v0.7.2)? If not, we will merge this PR and schedule the three removals.

Gates: golangci-lint 0 issues. (sandboxd, linux and darwin), fmt clean, go test -race ./pool/, e2e tests, asl unchanged.

[minatoaquaMK2]

Thanks for checking. This does not affect our current controller flow. It keeps replication and archive disabled, detaches before local hibernate, and reattaches after wake. The controller keeps the reservation across sleep, so it does not depend on archived-claim volume holds.

The controller uses per-entry attach_only: true. Our real-VM validation used Cocoon v0.7.3 and fresh journals. The proposed migration order for older SDKs, journals and Cocoon versions makes sense.

I applied our controller composition test on top of 668112e; it passes with -race. This is the HTTP/SDK test with a fake engine, not a new real-VM run.

No objection to removing these holds for our flow. This confirms the current controller branch and test setup; I haven't audited historical deployment records.