[mengmengmengqiang]

What

Closes the remaining gap of #538 on layerfs_v2_0_0: a Retained(Detach) custody (a forced unmount whose one plain detach the kernel refused EBUSY) was unrecoverable — every later workspace.unmount, force and sandbox.close re-reported the stored custody without re-attempting the detach, even after the holder exited.

Two pieces, matching the #541/#544 closing notes:

1. Typed-Evidence custody retry

• The forced teardown's undrained connection is now kept as typed evidence (Evidence::Undrained) instead of an erased Box<dyn Debug>, so a later terminal call can recover its KernelSession.
• Undrained::retry_detach (in layerfs-fuse) re-attempts only the recorded EBUSY detach after a fresh local drain; the abort write is never repeated.
• Service::take_retryable recognises the retryable custody (Detach, abort: Written, detach: Busy) and Service::retry_detach re-runs the detach. A ForceUnmount completes it as ForceUnmounted; a normal Unmount completes it as Unmounted (the control channel has no Unmount → ForceUnmounted correlation). A holder still present keeps the exact custody with the new detach disposition.
• The Sandbox-side unmount guard records retryable custody and re-sends it to the daemon instead of re-reporting it, so the retry actually reaches the daemon.

2. sandbox.destroy

An explicit operator/CLI verb that deletes only one Sandbox's data plane (runtime stop + delete, then its folder) without asking the daemon or settling commands — for an invisible #460 namespace-copy holder that exec records cannot see.

Tests

• macOS (host, pinned 1.85.1): cargo check/clippy -D warnings for layerfs-sandbox, layerfs-api, layerfs-cli, layerfs-node; cargo test -p layerfs-sandbox -p layerfs-api (incl. updated host_frame and calls_table); tools/check_product_boundary.py PASS.
• Linux (Debian rust:1.85.1-bookworm, real /dev/fuse, root): clippy -D warnings for layerfs-daemon + layerfs-fuse; the real FUSE forced_unmount FP-33 tests (cwd and descriptor) PASS with the new behaviour — re-report while held, Unmounted once the holder exits. stalled_unmount 7/7 PASS (run serially).

Not run

The full Sandbox E2E (client SIGKILL during foreground exec → force Busy → workspace.exec_cancel → Unmounted) still needs the sealed Linux bundle and its sandbox-image.tar, which this host does not have built; the daemon-level FUSE proof above covers the custody-retry half directly.

Related: #538, #460, #541 (superseded), #544 (superseded).

Rebase and re-verification (2026-11-12)

Rebased from the fork point 833d04cf4 onto layerfs_v2_0_0 @ 03883a63c
(which now includes #639/#641/#621/#543/#547/#655). Four commits kept, authorship
unchanged. New head: 4020e9097.

Conflicts and semantic merges:

• control/crates/layerfs-sandbox/src/family.rs — the base's get re-export
  gained Down while this branch adds destroy; kept both
  (pub use super::get::{get, Down, ...} plus pub use super::destroy::{...}).
• control/crates/layerfs-sandbox/src/host/call.rs — the base added
  Op::Capacity and this branch adds Op::SandboxDestroy, so OPS has 11
  entries. The auto-merge left the old length 10 and did not compile; the length
  is fixed inside the first commit so every commit in the stack builds.

Verified on Dell (aluminium, Linux x86_64, cargo 1.85.1) at the stack head
995627e09 (this branch plus #653/#654): cargo fmt --all -- --check and
cargo clippy --locked --workspace --exclude layerfs-node --all-targets -- -D warnings
exit 0, and cargo test -p layerfs-sandbox -p layerfs-control -p layerfs-api
passes 103 binaries / 297 tests / 0 failures / 4 ignored (the four FUSE mount
targets run as root under flock /tmp/dell-fuse.lock; /dev/fuse left at 666).

The clippy (u64::from(blocks_available()) useless conversion in
control/crates/layerfs-home/src/home/capacity.rs) and test
(sdk_blame_coarse::lines_between_distant_edits_keep_their_origin) failures
seen on the stacked PRs came from this branch's old base and are fixed by
03883a63c.

CI note: PRs into layerfs_v2_0_0 are exempt from the ci workflow
(branches-ignore), so this PR shows no checks by design; the same tree was
checked by the ci runs on #653/#654 and by the Dell run above.

[mengmengmengqiang]

Problems this PR (and its follow-ups) fix

This PR is the base of the #538 custody stack: #640 -> #653 -> #654. Together they close:

• A normal-unmount retry completed as ForceUnmounted. The retry path and the force path shared one terminal answer. fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640 completes it as Unmounted.
• Detach from Retained custody was not retried. A workspace left Retained after a forced detach could not be retried once the holder was gone. fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640 retries the detach and adds sandbox.destroy.
• A Retained unmount could not be retried (fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653). The live mount table no longer answers a Retained Workspace, so the token has to come from its record. fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653 reads the token from the workspace record.
• sandbox.close deleted the data plane instead of retrying (fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654). With the pool full, a non-force close destroyed uncommitted Workspaces. fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654 retries the retained detach and refuses Busy instead of forcing.
• force was the only recovery. After fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654, close/status/reclaim no longer require destroying the data plane; force remains the last resort.

Position in the stack: base. Merge order is #640 -> #653 -> #654; #653 targets fix/538-custody-retry (#640's branch) and #654 targets fix/538-unmount-retry, so they rebase and retarget as the one below them merges.

Why split into separate PRs

• One invariant per PR. fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640 fixes the daemon-side retry/destroy, fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653 the workspace-record token path, fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654 the sandbox.close path. They are three different entry points; a single PR would mix three failure modes and three test sets.
• Each is independently revertable. If the close path regresses, fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654 can be reverted without touching the unmount retry (fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653) or the daemon core (fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640).
• Different layers, different reviewers. fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640 touches the daemon's custody machine; fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653/fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654 are the sandbox control surface. Keeping them separate keeps the review scope honest.
• Decoupled from the slot stack. Unmount: force while a foreground exec orphan holds the mount leaves Retained(Detach), and later unmount/force/close cannot recover #538 is custody/mount, not admission slots; it is a separate stack (fix(daemon): retry detach from Retained custody and add sandbox.destroy (#538) #640 -> fix(sandbox): retry a Retained unmount through the workspace record's token (#538) #653 -> fix(sandbox): retry retained detach on close instead of deleting the data plane (#538) #654) so neither problem's review depends on the other.