afx cleanup: '[ok] cleaned up' when only deregistered — worktree-preservation is inconsistent and the message misrepresents it

[waleedkadous]

Problem

afx cleanup -p <id> prints [ok] Builder <id> cleaned up! in two very different situations:

1. Full cleanup — registry row removed, worktree removed, branch deleted.
2. Deregistration only — registry row removed, but the worktree and branch are preserved on disk (with [info] Worktree preserved at: ... lines above the [ok]).

The [ok] cleaned up! reads as case 1 either way. An operator (or agent) scanning outcomes sees success and later finds .builders/ still populated — and by then the registry row is gone, so afx cleanup can no longer address the leftover at all ("Builder not found", the #1102 row-less gap). The tool's own preservation path manufactures row-less worktrees.

Observed inconsistency (two workspaces, 2026-08-02/06)

• This repo's sweep: builders with tracked modifications (e.g. a modified package-lock.json) were preserved; builders with untracked-only dirt (builder artifacts, porch state) were fully removed — both printed [ok] cleaned up!. Neither the criterion nor the outcome difference is stated in the output.
• A sibling workspace reports the same shape: two builders deregistered-but-preserved (one was checked out on a non-canonical branch, which may be a second preservation trigger; the other was on its canonical builder branch), a third under near-identical conditions fully removed. Same [ok] for all three.

Asks

1. Honest messaging: when preserving, say [warn] Deregistered only — worktree preserved (uncommitted changes / non-canonical branch): <path> and exit distinctly, so scripts and agents can branch on it.
2. Document (or make configurable) the preservation criteria — tracked-dirt vs untracked-dirt vs branch-mismatch is currently reverse-engineered folklore.
3. Reachability after preservation: preserved worktrees should remain addressable by a cleanup form (ties into afx cleanup: no row-less teardown path + '-i <issue>' never matches bugfix builders (issue_number TEXT vs number ===) #1102's row-less teardown path) rather than requiring manual git worktree remove.

Related: #1102 (row-less teardown + -i bugfix matching), #1101 (SPLIT states).

[waleedkadous]

Repro data from the reporting workspace (sanitized). One sweep, four worktrees, all push-verified (local HEAD == origin branch; all PR content merged to the default branch) before cleanup:

Case	Checked-out branch	Dirt	Result
A	canonical builder/<id>	1 untracked (hooks .cjs)	Fully removed, remote branch deleted
B	non-canonical follow-up feature branch	15 untracked (consult ephemera under codev/projects/ + hooks .cjs)	[ok] cleaned up! but only deregistered — dir + checkout remain
C	canonical builder/<id>	1 untracked (hooks .cjs only)	Same as B — reported cleaned, dir remains
D	canonical	1 untracked	Registration lost in an earlier session crash → cleanup -p <id> and -p <name> both 'Builder not found' (the #1102 row-less gap)

Notes:

• A and C are near-identical (canonical branch, single untracked hook file, HEAD = one status.yaml-only bookkeeping commit ahead of default) yet diverged — so neither non-canonical-branch nor tracked-vs-untracked dirt fully explains the preservation trigger on our data.
• The preserved cases' output prescribed only git branch -d <name> — it never printed a git worktree remove <path> follow-up — so the 'tool-prescribed removal step' unblock suggested in this issue does not exist in the output as shipped; the leftover directory has no sanctioned path at all from the operator's seat.
• In all cases the success line [ok] Builder <name> cleaned up! was identical whether the worktree was actually removed or not.