bug: pool-managed mayor spawns alongside [[named_session]] mayor and loops on failed-create due to session_name collision

[sjarmak]

Before you continue

• Related-but-distinct from bug: controller's session reconciler doesn't know how to claim and start pool-managed sessions that lack a [[named_session]] entry #758 (CLOSED — "controller's session reconciler doesn't know how to claim and start pool-managed sessions that lack a [[named_session]] entry"). This is the inverse: [[named_session]] entry PLUS poolDesired for the same template both fire simultaneously, and the pool manager keeps spawning ephemeral mayor beads that can never reach the active state.
• Observed while recovering from bug: reconciler stuck in drain-log loop: session with orphaned in-progress work beads can't close, ~65% dolt CPU sustained #855, but a distinct bug.

Environment

• Gas City: 0.15.x (gc commit b6cef0c9)
• Workspace: ds-research (single-city managed-dolt)
• City config has both:
  • [[agent]] name = "mayor"
  • [[named_session]] template = "mayor" mode = "always"
• Observed after a supervisor restart on 2026-04-19 12:16 EDT.

Symptom

gc session list shows two mayor beads in steady state:

id	state	target	session_origin	pool_managed	notes
gc-1432	active	mayor	named	false	the real, working mayor
gc-1947	creating	mayor-1	ephemeral	true (slot=1)	never leaves creating

Before gc-1947, the reconciler had already closed gc-1945 with state: failed-create / close_reason: failed-create. Each new pool-managed mayor bead gets a unique session_name: mayor-gc-NNNN (non-colliding with "mayor") and target mayor-1, but creation still fails and the pool manager retries indefinitely.

Supervisor log excerpt

poolDesired: mayor = 1
scaleCheck:  mayor = 1
session reconciler: starting mayor-gc-1945: context canceled
session lifecycle: op=start wave=0 session=mayor-gc-1945 template=mayor outcome=canceled

Also:

session beads: session_name "control-dispatcher" for control-dispatcher unavailable: session name already exists: "control-dispatcher" conflicts with existing identifier on gc-1928

— same pattern for the control-dispatcher template (a pack-imported agent). So this is not mayor-specific; any agent template with both an [[agent]] block and a matching (explicit or implicit) named-session can trip it.

Expected behavior

[[named_session]] for a template should suppress poolDesired for the same template (or vice versa). Spawning both simultaneously should either:

1. Be rejected at config load with an error explaining the collision, or
2. Converge on the named session and skip pool scaling for that template, or
3. Allow both but assign non-overlapping identity so creation actually succeeds.

Relation to #855

Observed during #855 recovery. Not the same bug, but possibly an amplifier — each failed-create retry runs its own bd probes against the rig store, adding to the very queue #855 describes. Might be worth touching in the same area of the codebase.

Reproduction (sketch)

1. Fresh city with [[agent]] name = "mayor" AND [[named_session]] template = "mayor" mode = "always".
2. gc supervisor start.
3. Watch gc session list — expect a single active mayor; observe two beads (named + ephemeral pool).

Happy to produce a minimal repro city if that would help.

[quad341]

Picking this up. Plan: TDD — failing test first against the config loader / pool reconciler seam, then implement collision detection or pool-suppression for templates that also have a [[named_session]]. Will open PR linked here. Also mirrored + claimed on wasteland as w-b637cd46c3.

[sjarmak]

Filed the continuation_reset_pending recovery quirk from my earlier comment as #930 — it's a distinct wake-state-machine mechanism from #909's pool+named collision, so separating it so it doesn't get lost here when you close #909.