Reclaim the tagged derivative subtrees

[blooop]

Work

Reclaim the tagged derivative subtrees, per the decision on #468. ~94.5 GB of the measured 104.5 GB, which is this map's whole principle-2 payoff.

Sliced out of #454 because it is a different unit (a tagged directory paired with its recipe, not a site subtree) and its own PR's worth of work. Blocked on #454 rather than parallel to it, because the claimant fold it needs is that ticket's Reason::subject().

• The Tagged / Derivative / Recipe / NoRecipe types. Derivative has private fields and no Default; Option<Derivative> is refused as two meanings in one value. A public-api.rest.txt row asserts the absence of any other constructor.
• The gate is the Cache Directory Tagging Specification's published 43-byte CACHEDIR.TAG signature, and the walk does not descend past a tag. The predicate must never read a directory's name: measured present from rattler, cargo, uv and pytest, and absent from python -m venv and npm's node_modules, so the same name lands on both sides.
• The three-read pixi reader: environment_name only, pixi.lock located by walking up inside the site, and manifest_path never stored — it is a container path on every host env, the trap What unit does the agent-worktree sweep reason about #445 and What proves an agent worktree safe to remove, and what if it cannot be proved #446 answer by never resolving a recorded path.
• The claimant fold: a standing reason reaches the subtree only when its subject is a claimant (ThirdPartyClaim, CouldNotTakeTheLock, a nested site), never when it is git's account of content. Derived from What proves an agent worktree safe to remove, and what if it cannot be proved #446's verdict, not chosen.
• Bytes through exclusive_usage (R3). The plan names each derivative and its size before the y/N, and the acting pass re-reads both records.
• Remove the tagged directory alone and never .pixi, which holds config.toml.
• No new flag. It is a removal with a proof; hanging it on --force-worktrees would make one flag carry two consents, which Does --purge need an unsaved-work check #459 refused.
• Recipe cases, each a test row: lock present and naming the env re-derives (measured 5507/5507 files in 0.52 s with every proxy at a dead port); lock absent refuses and the tree stands; lock stale still re-derives what was there; an env the lock no longer names stands, with pixi clean -e as the pointer.
• Fixture rows that prove the predicate never reads a name: a node_modules and a stdlib .venv present, and nothing happens to them.

Two refuted alternatives, recorded so nobody retries them: the per-file proof (union conda-meta's files arrays, call the rest foreign) fails at 1208 false positives out of 12210 on this repo's real env, because the pypi half lives in .dist-info/RECORD and __pycache__ is recorded nowhere. And pixi does not defend its own tag — a planted my-notes.txt and a hand-written site-packages/mypkg both survived pixi install --frozen unmentioned. The argument rests on the disjoint-byte-sets reading, never on "everything in there was installed".