workspace cleanup plan should stream progress or expose current scan phase

[chubes4]

Problem

When workspace cleanup plan --mode=retention runs on a large workspace, it can sit silently for multiple minutes. Today it emitted no output before a 120s timeout, then emitted no output again before the operator aborted a long retry.

Why this matters

A silent cleanup planner is hard to distinguish from a hang, a GitHub/API stall, a lock wait, or an expensive per-worktree scan. This makes the safe cleanup path feel broken even when it might eventually complete.

Prior related work

• Cleanup commands should stream progress and identify the current worktree #186: Cleanup commands should stream progress and identify the current worktree
• Make workspace worktree cleanup fast, bounded, and recoverable #550: Make workspace worktree cleanup fast, bounded, and recoverable

Those improvements do not appear to cover this workspace cleanup plan path.

Suggested behavior

• Print an immediate header with the mode, workspace root, inventory size, and whether GitHub/status/du probes will run.
• Emit periodic progress lines or structured JSON events with the current phase and counts scanned/classified/skipped.
• If waiting on a lock, print the lock owner / age / retry plan.
• If planning is intentionally delegated to jobs, return a run id and a status command immediately.

Acceptance criteria

• Operators can tell within a few seconds whether planning is working, waiting, or stuck.
• Long-running plan commands expose a resumable run id early enough that aborting the terminal does not waste the whole scan.