workspace cleanup plan is still too slow on large workspaces

[chubes4]

Problem

studio wp datamachine-code workspace cleanup plan --mode=retention is still too slow for the large local workspace case.

Evidence from 2026-06-11

• Ran from /Users/chubes/Studio/intelligence-chubes4 after workspace list showed hundreds of registered primaries/worktrees.
• Command: studio wp datamachine-code workspace cleanup plan --mode=retention
• First run produced no output before the shell tool killed it at 120s.
• Second run was retried with a 20 minute shell timeout and still produced no output before the operator aborted it.

Why this matters

The documented daily cleanup path is workspace cleanup plan followed by workspace cleanup apply <run-id>. If planning takes minutes with no visible progress, agents/operators are pushed toward lower-level cleanup commands or manual deletion, which defeats the safety model.

Prior related work

• Make workspace worktree cleanup fast, bounded, and recoverable #550: Make workspace worktree cleanup fast, bounded, and recoverable
• Workspace cleanup orchestrator hangs on full workspace scan #415: Workspace cleanup orchestrator hangs on full workspace scan
• fix(workspace): make worktree cleanup scale on large workspaces #116: fix(workspace): make worktree cleanup scale on large workspaces

Those are closed, but today's behavior suggests the retained plan path still has an unbounded or high-latency scan in large workspaces.

Acceptance criteria

• workspace cleanup plan --mode=retention returns an initial run id or progress status quickly on a workspace with hundreds of worktrees.
• The command should not perform a long silent scan before emitting a resumable identifier.
• Planning should use bounded pages / continuation where possible, or clearly delegate to jobs and return immediately.