[OfficialAbhinavSingh]

Stacked on #78, so merge that first. Control plane and frontend only, with no gateway or contract change.

What was broken

Found by running a plan on app.mergit.site (plan c8d22b3f). Task 1 of that plan errored at 05:45:50. Its retry with the second agent never ran, and the task said "Retrying" for good.

• The retry gave up after 10 minutes. The gateway won't lock attempt n while attempt n-1 still holds its payment (ingress.rs:141-158, 503). An attempt that ended without a receipt only gets that payment back at its deadline, 30 minutes after dispatch, once the keeper returns it. Meanwhile the outbox gave task.dispatch_requested up after event_retry_window_s (600s), and nothing read it again.
• One stuck retry blocked its whole plan. The outbox sends a plan's events in order, so every later event of that plan waited behind the stuck retry, Close plan included.
• A stuck task only offered Close plan. There was no way to send it to another agent.
• Host failures counted as agent failures. The missing sandbox image failed every job, and each failure used up one of the requester's agent picks.

What changes

Retries

• A retry's dispatch is delivered until its earliest possible lock plus 10 minutes. Its deadline is counted from when it can lock (the previous attempt's deadline plus RETURN_MARGIN_S), not from when it was queued.
• While it waits, it holds up no other event of its plan.
• A reverted lock (the gateway's error event for a dispatch) marks that dispatch given up, so the task waits on the requester instead of saying "Retrying" forever.
• Only the newest attempt retries on its own. A task that passes cancels its dispatches that haven't gone out yet.

Closing a plan

• Close plan cancels the plan's dispatches that haven't gone out, so nothing locks money after the requester gave up.

Retrying a stuck task by hand

• POST /v0/plans/{uuid}/tasks/{index}/retry {agent_id} sends a stuck task to an agent the requester chooses, up to max_requester_attempts (6) attempts per task.
• It refuses (409) while an earlier attempt still holds its payment behind a given-up dispatch. The gateway only checks attempt n-1, so without this a retry could lock a second payment from the plan's shared balance. That check reads the ledger, so it lives in money.py, and the graph side still never reads money events.

Plan detail

• The plan detail returns pending_dispatches, stuck_indexes and max_requester_attempts.

Run page

• Stuck tasks get an agent picker and a "Retry with this agent" button next to Close plan.
• The task panel says what a retry is waiting on.
• The page reloads while a retry is pending, because the stream carries jobs, not dispatches.

Worker

• The worker refuses to start without its sandbox image, so jobs stay queued instead of failing.

Database

• Migration 0023 indexes the outbox by a dispatch's task_id.

Checks

• Control plane: ruff, ruff format and pyright clean. 558 unit tests pass, plus 466 against Postgres.
• New tests cover the retry window and deadline, the reverted lock, closing a plan, the late older attempt, cancel on pass, the holding refusal, the slot rule, and the endpoint (422/409/404/403/200).
• I broke each fix on purpose and its test caught it (10 of 10).
• Frontend: tsc, eslint and prettier clean. vitest 515/515. Live e2e 115 passed, including a new "a stuck task can be sent to another agent" test.
• Full e2e: only the two long landing scroll tests fail under full-suite load, the same as on main. They pass on their own.
• Checked the run page in light and dark at 1440 and 390 wide, with no horizontal overflow. The agent picker wraps under its label on phones.
• An independent review of the first commit found the deadline, reverted-lock, late-attempt and second-lock problems. The second commit fixes all four.

Known limits

• A retry after an errored attempt still waits up to about 31 minutes for that attempt's payment. Returning an attempt's payment as soon as it errors needs a new Escrow function and a gateway change, which is out of scope here.
• Closing a credits plan while a task is still locked loses that task's money from the requester's credits. The gateway watcher only restores credits from PlanClosed.refund, so that's for the gateway owner.
• If a dispatch looked given up but its lock actually landed later, its job still runs.