feat(worktree): report reapable venvs behind nine conjuncts, delete none

[wshallwshall]

Virtual environments are 19.66 GB, 83 percent of a 63 GB worktree class. .venv/ is gitignored and
constraints.lock is tracked, so a venv is rebuildable state: deleting one costs a rebuild, deleting
a worktree costs work. Different blast radii, so different gates.

This reports. It deletes nothing. Every adversarial pass over a reaper for this workspace returned
NEEDS_A_GUARD, so the deliverable is the dry run.

There is no venv deletion path, verified three ways

An independent verifier established this before the branch was opened.

Armed first. The removal-verb search fires: run against scripts/worktree/remove.ps1 it returns 3
hits including a live Remove-Item -LiteralPath $f.FullName -Force -EA Stop. The same pattern over
this branch's added script lines returns 0.

Cmdlet inventory over the whole new block: Test-Path, Get-ChildItem, Get-Item, Join-Path,
Split-Path, Measure-Object, the *-Object filters, and the script's own helpers. No removal verb
of any kind. Every git call it reaches is rev-parse, for-each-ref, status --porcelain or
gh pr list.

Asserted on disk, not on the report. test_there_is_no_venv_deletion_path_anywhere_in_the_script
runs -ReapVenvs -Apply, gets REAPABLE, then asserts pyvenv.cfg and site-packages/mod.py still
exist.

The exit-code defect this branch introduced, and fixed

Set-Exit $EXIT_REFUSED ran at line 1223, before $removed is initialised at 1477, so it could not
carry the guard the -Name path has at 1717. A -ReapVenvs -Apply run could remove worktrees and
still exit 2, which the header defines as REFUSED, nothing was attempted.

Reachability was established by walking the AST, not by grep -- every exit, return, throw,
break and continue between the two points was classified by whether it sits inside a
FunctionDefinitionAst. None can terminate the script or skip the apply loop. Set-Exit is defined
once and has no side effect.

Red before, green after:

AssertionError: removed 2 worktree(s) and reported exit 2;
                2 is documented as REFUSED -- nothing was attempted
2 failed, 98 deselected          LASTEXITCODE: 1

5 passed, 95 deselected          LASTEXITCODE: 0

The three neighbouring refusal tests run as controls in that second set: they are dry runs and must
stay at exit 2. The refusal cause is C9's absent transcript store, not -IdleHours 0, so the removing
half and the refusing half move independently.

Exit 2 is still not a promise that nothing happened, and the docs now say so

A mid-run fence death refuses inside the apply loop and carries no $removed guard either. A run can
remove two worktrees, lose the fence on the third, and exit 2.

That is not fixed here. It is a second behaviour change to a destructive tool's exit codes and it
was not briefed. Both copies of the enumeration now read "something you asked for was not attempted"
rather than a repaired universal, which is true of every path. The -Name path carries the identical
hole and is also untouched.

Four sites carried the claim, at three different counts

scripts/worktree/prune-merged.ps1:120   the header enumeration
scripts/worktree/prune-merged.ps1:256   an inline comment on $EXIT_REFUSED
docs/WORKTREES.md:325                   the doc copy
docs/WORKTREES.md:227                   asserts it without using the phrase

The fourth was found by searching every mention of "exit" rather than the phrase. The header wraps the
phrase across two lines, so a line-oriented grep misses it -- the surviving occurrences were verified
with a multiline pattern against an origin/main control that returned 1 and 2.

Readings

python -m pytest tests/test_worktree_prune_merged.py
100 passed in 245.16s        LASTEXITCODE: 0

Baseline was 98; the two new tests are the delta. git rev-parse HEAD and git status --porcelain
were identical before and after both full runs, so neither measured a moving tree. PowerShell parser:
0 errors. Non-ASCII in the script: 0, against a control on docs/WORKTREES.md returning 185.

Live receipt, read-only, one -RepoRoot per repository: 67 venvs across 108 of 109 registered
worktrees, 0 reapable, 51.13 GB held, stopped by C6 clean 42 and C7 idle 25.

What is measured and what is not

C9 has decided nothing yet. It fails on all 67 trees and was the deciding conjunct on zero of
them -- every one was already stopped by a lower-numbered check. Its marginal contribution is
unmeasured, not disproven, and it should not be published as having saved anything.

Nine conjuncts are seven per-tree predicates plus one population gate plus one run-level gate. C3 is
recorded PASS on every row unconditionally, because reaching the row already means it passed.

docs/WORKTREES.md:213 now records what the venv pass does NOT reuse from the worktree rule:
Get-NestedWorktrees, which vetoes a tree containing another registered worktree. Dropping it is
sound -- removing a parent orphans its children, which cannot happen when you delete only .venv --
and nothing recorded the drop until now. Confirmed by call-site enumeration at 686, 819 and 1542.

[github-actions]

Security failed while this pull request was in the merge queue, so the queue ejected it.

Its own head can still be green: the queue revalidates the merge, and the path gates that skip on a pull request run there. Read the run before retrying.

https://github.com/MEFORORG/MessageFoundry/actions/runs/35276993902