run: route a lead BLOCKED on git/gh writes to a worker for one more cycle

[kokevidaurre]

Follow-up to #875 (convergence defect)

#875 fixed the data-loss half: a per-run worktree with uncommitted work is now auto-committed to the run branch before cleanup, so deliverables are never silently destroyed.

This issue tracks the convergence half, still open:

When a lead's review turn ends ## STATUS: BLOCKED because it could not get approval for sandboxed git/gh writes (commit / push / open PR), the conversation terminates. The work is now preserved on the run branch (#875), but no PR is opened and goals/state are not updated — the run is preserved but not delivered.

Workers can perform these writes (some squads already self-deliver by delegating git/gh to a worker rather than the lead doing it directly). So the convergence loop should:

1. Detect a lead turn that ends BLOCKED specifically on write-approval (vs blocked on missing information).
2. Run one additional cycle that routes the enumerated write operations (commit, push, gh pr create, gh pr merge --auto) to a worker instead of terminating.
3. Cap at one recovery cycle to avoid loops.

Acceptance

• A run where the lead hits a write-approval block ends with the PR opened by a worker, not with STATUS: BLOCKED and a list of commands for a human to run.

Related: #875 (data-loss half, fixed), workflow.ts review phase.