🤖 task_remove lossy-work check: remaining gaps after #4744

[ThomasK33]

Context

PR #4744 (Refs #4723) makes a model-driven task_remove refuse to force-remove a sub-agent checkout that holds work nothing else preserves. Review found edge cases the check does not cover. In each one the work was already lost before #4744 (removal never checked anything), so they were deferred instead of growing that PR.

Gaps

1. Live writers (TOCTOU). A background bash process, terminal or external editor in the child checkout can write between the check and the forced removal. Needs an activity admission hold like the archive path's (acquirePreInterruptionArchiveHold), or a refusal while such writers exist.
2. Commits on other local branches. The check (and patch generation) only inspect base..HEAD. For standalone-copy runtimes (Docker, SSH clones), removal deletes the whole repository, including commits on branches the child created and then switched away from.
3. Unusable mbox. hasMbox uses fs.access; a directory at series.mbox counts as a payload, while resolvePatchPath requires a regular file. Needs corrupted session state.
4. Existence probe. [ -e <checkout>/.git ] reports "no" (check skipped) when traversal fails with EACCES or .git is a dangling symlink.
5. Scratch sub-agents. Non-git workdirs are not checked; a non-empty scratch workdir could be treated as lossy.
6. UI. No per-sub-agent removal with a dirty-checkout confirmation exists: sub-agent rows hide archive/remove, and the palette "Remove Current Workspace…" does a non-force remove and silently drops the error. Deleting the parent workspace is the only confirmed user path.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $45.38

[linear-code]

MUX-287