fix(mail): sweep every box, bounded per pass, and say when a pass stopped short

[wshallwshall]

The retention sweep was scoped to the current worktree's own box, so a box whose worktree is gone
never drained. Measured before this branch: 23,812 of 24,205 seen/ files were already past a rule
meant to delete them.

Widening it is correct and it means the first pass has a five-week backlog to clear. That is the rest
of this branch.

The first widened pass would have been killed, and taken the mail with it

mail-drain.ps1 is registered on SessionStart and Stop with "timeout": 20 -- twelve
registrations across six config roots, read from each root's settings.json.

The first pass reaches 33,159 files: 23,861 in seen/, 52 in expired/, 36 markers, and 9,210
receipts after the guards. At a measured 0.77 ms per Remove-Item plus Test-Path, that is about
25.5s of deletes plus roughly 5s of fixed cost, against a 20s kill.

The consequence is worse than a slow sweep. Delivery is the LAST thing the drain does -- box loop,
receipt sweep, dead-owner sweep, marker-orphan sweep, then the delivery passes and the injection. A
pass killed inside the message loop delivers no mail at all that turn.

Three budgets, not one

Phase	Constant	Value
seen/ and expired/, every box	$MESSAGE_DELETE_BUDGET	1000
shown/ markers	$MARKER_DELETE_BUDGET	250
receipts/	$RECEIPT_DELETE_BUDGET	1000

Separate budgets are the structural fix for the failure being repaired: a seen/ backlog can never
spend the receipt phase's allowance, so the receipt sweep cannot be starved by the phase ahead of it.

2,250 deletes cost 1.73s, so a full pass is about 7.0s -- 35 percent of the 20s cap. Sized against
multiples because the benchmark had no on-access scanner in its path: 10.5s at 3x, 14.0s at 5x. The
backlog clears in 24 message passes and 10 receipt passes.

The receipt phase budgets its deletes, not its scan. Capping the candidate list would wedge: a
block of guard-protected receipts at the front of the enumeration would refill it every pass and hide
everything behind them forever.

A truncated pass says so, and a finished one stays silent

1000 message(s) older than 7 days were removed from seen/ and expired/ across 2 box(es) examined.
The seen/ and expired/ sweep stopped at its per-pass budget of 1000 delete(s)
without reaching the end of its input. The rest is still on disk and the next drain resumes.

Next pass, same tree: 25 message(s) ... removed.

The flag means "did not reach the end of its input", set only where a file or box was left
unexamined. It is never derived by comparing a counter to its cap, so a pass whose last delete
happened to be its last candidate is finished and says nothing.

Readings

Red first, against the drain at 0bb2605b4 extracted to a throwaway file so both arms run the same way:

AssertionError: the pass did not stop at the budget, so the hook's 20-second kill is still reachable
AssertionError: the message phase never hit its budget, so this arm proves nothing
2 failed          exit: 1

Green after:

3 passed, 44 deselected in 13.33s          exit: 0

The third is a permanent planted control: budgets rewritten to 10,000,000, the whole pile dies,
and no truncation line prints. A bound sweep and a broken one cannot pass identically.

Full suite across both session-mail files: 122 passed in 182.59s, exit 0, against a 119 baseline.
HEAD and porcelain identical before and after.

The guards, verified independently before this branch opened

Each of C5, C8 and never-both-halves has a planted survivor AND a must-delete plant beside it. The
branch ships its own negative control that rewrites Test-ReceiptProtected to return $false and
asserts all six survivors die. A verifier separately mutated two guards and watched them go red, then
restored the file to a matching SHA256.

The state filter is byte-for-byte unchanged. @('seen', 'expired') -- inbox, claiming and
stranded are absent from both refs. That filter alone stands between this sweep and 285 undelivered
messages plus 6 rescue records: with inbox added to the delete list, the C5 receipt test still
passed while the messages it protects were destroyed. C5 does not backstop it.

Corrections carried in this branch

C8 protects 1 file today, not 16. It finds 16 cited stems; 15 are already held by C5. The "(16)"
appears only in an earlier commit message, which cannot be amended, so the accurate figure is now in
docs/SESSION-MAIL.md beside the guard, with the reason an overstated guard invites its own deletion.

The docs named a date the code stopped reading. The exclusion became the _retired- family,
matched as a whole path segment, because scripts/coord/handoff.ps1 builds "_retired-$stamp" from
the current date on every retire. docs/SESSION-MAIL.md still said _retired-2026-08-22/.

The condition not varied

Every figure is from this machine on 2026-09-17. The delete benchmark ran in a throwaway temp
directory with no on-access scanner, which is why the budget is sized against multiples of it rather
than against the number itself.