bug(gastown): create_landing_mr loops infinitely when convoy branches have no PR URL

[jrf0110]

Summary

The reconciler's create_landing_mr action has no circuit breaker. When a convoy's branches don't have associated PR URLs, the landing MR creation fails immediately at the system level, the reconciler sees the convoy still needs a landing MR, and retries on the next tick — forever.

Observed in production on town 5f5fda7f-00fe-4656-8493-602a4da9f8dc (org 9d278969-5453-4ae3-a51f-a8d2274a7b56):

Metric	Value
Convoys stuck	2 (efc19f22, f8bec2cd)
Loop duration	~42 min (16:57–17:38 UTC, still ongoing)
Failed MR beads created	240
Invariant violations	257 (mostly "Rig has 2 in_progress MR beads")
Cycle rate	~1 every 10-15s per convoy
create_landing_mr reconciler actions	186 in last 42 min

The Loop

reconciler tick
  → detects convoy needs landing MR
  → emits create_landing_mr action
  → MR bead created ("Review: convoy/fix-.../head")
  → MR bead immediately fails (system-level, "by agent system")
  → reconciler tick
  → detects convoy STILL needs landing MR (old one failed)
  → emits create_landing_mr again
  → repeat forever

The debug endpoint shows sideEffectsAttempted: 0, sideEffectsSucceeded: 0, sideEffectsFailed: 0 — the failure is happening at validation before the Git API call, likely because there's no PR URL on the convoy's source branches.

Root Cause

The reconciler has no guards on the create_landing_mr path:

1. No max retry count — create_landing_mr is emitted every tick as long as the convoy needs one and the last one failed
2. No PR URL validation — the action is emitted even when the convoy's branches have no associated PRs
3. No cooldown — new MR beads are created before old ones fully transition to failed, causing the "2 in_progress MR beads" invariant violation
4. No convoy-level failure escalation — the convoy stays open forever, never fails or escalates

Suggested Fixes

1. Guard create_landing_mr — before emitting, check that the convoy's completed beads actually have PR URLs. If not, skip and log a warning (or escalate).
2. Max landing MR attempts per convoy — track landing_mr_attempts on the convoy record. After N failures (e.g., 3), fail the convoy and escalate rather than looping.
3. Deduplicate MR bead creation — don't create a new MR bead if one for the same convoy is already open or in_progress.
4. Cooldown between attempts — if a landing MR fails, wait at least 60s before retrying (not every 5s tick).

Relevant Code

• Reconciler create_landing_mr emission: services/gastown/src/dos/town/reconciler.ts (convoy reconciliation section, ~line 1493+)
• Landing MR action handler: services/gastown/src/dos/town/actions.ts
• Review queue MR creation: services/gastown/src/dos/town/review-queue.ts (submitToReviewQueue, ~line 110)
• Convoy progress tracking: services/gastown/src/dos/town/reconciler.ts (reconcileConvoys, ~line 1516)

Related

• Also related to the per-bead review loop (MR beads created without pr_url for non-convoy beads) — same missing guards but different trigger path. The per-bead path goes through agentDone → submitToReviewQueue → refinery dispatch → fail → reopen source → re-dispatch polecat → loop.
• audit(gastown): Reconciler code quality audit — bugs, gaps, and hardening recommendations #1986 (reconciler code quality audit) — finding feat(cloud-agent): new worker for new kilo cli based on focus-week branch #14 flagged missing convoy failure handling

[jrf0110]

Additional finding from #2345/#2346

Town d02a003a hit this exact bug — 5,335 create_landing_mr actions over 41 hours, producing ~5,572 failed MR beads.

New data point: gt_convoy_close does not reliably stop the loop. The user's first close at 2026-04-12 16:19:20 UTC had no effect — the loop continued for another 15.7 hours. Only the second close at 2026-04-13 08:00:02 UTC stopped it. This suggests either:

1. A race condition where update_convoy_progress (emitted on the same reconciler tick) reopens the convoy after close
2. Or gt_convoy_close failed to actually transition the convoy to closed in the DB

This means even the manual remediation path (having the mayor force-close the convoy) is unreliable. The fix needs to be in the reconciler itself — handle status = 'failed' landing MRs with a retry limit rather than unconditionally re-creating.

[jrf0110]

Scope addition: Bulk bead deletion

The create_landing_mr loop can leave thousands of failed MR beads in a town's DB (town d02a003a had 4,806). We need a way to clean these up efficiently.

Requirements

1. gt_bead_delete tool — accept either a single bead_id: string or an array bead_id: string[]. The mayor already used this to delete 766 beads one-by-one during cleanup, which is painfully slow.

2. Beads page (user UI) — add a bulk select + delete action. Users should be able to filter to failed beads and delete them in bulk (e.g., select all → delete, or filter by type/status and bulk delete matching).

3. Admin panel beads tab — same bulk delete capability for admins investigating towns.