fix(managed-agent): residual admission gap-lock deadlock on the shared command index (mutation-admission siblings) #13374

What happened?

PR #13365 removed the deposition-critical gap-lock shape behind #13333 (insertTurnCommand's FOR UPDATE replay probe) and proved the deterministic N−1 admission deadlock gone. One narrower window of the same InnoDB gap-lock family remains open on the tenant-shared managed_agent_command index, verified by code inspection during that fix's review and disclosed in the PR:

1. Mutation-admission siblings keep the old locking-probe shape. beginSessionMutation and unarchiveWorkspaceSession still probe the idempotency command row with a FOR UPDATE read that — when the row does not exist — next-key-locks a gap of the tenant-shared index, and their service callers (renameSession, unarchive) have no DuplicateKeyException replay fallback. Two concurrent same-tenant mutations on different sessions can therefore deadlock the same way (one 500 after InnoDB kills the loser), and two same-key concurrent mutations surface a raw 500 instead of an idempotent replay.

2. Creation scope catch path, same-key triplicate race. CLOSED (2026-10-04, PR fix(managed-agent): stop gap-locked replay probes deadlocking same-tenant admission bursts #13365 head 1f2ffe30a5). The requireCreationScope rewrite that created this window (plain INSERT + DuplicateKeyException catch + FOR UPDATE re-read) deadlocked N−2 same-key racers because each failed duplicate check retains a shared lock on the committed row and the upgrades cross-block — measured on a JDBC probe against MySQL 8.0.46 with 8 barrier-released racers (7/8, 7/8, 6/8 losers killed), while the base ON DUPLICATE KEY UPDATE sequence queues the losers on its exclusive lock (0/8 every round). The hunk was reverted to the base sequence exactly; the window no longer exists. Context in this comment and in the PR delta comments.

What did you expect to happen?

Concurrent same-tenant admissions of every kind — turns, session creates, and lifecycle mutations — must never deadlock or surface lock errors; same-key races must resolve to a deterministic replay or 409 idempotency_conflict, never a 500. For window 1 that means routing the mutation siblings through a service-side replay that preserves beginSessionMutation's FAILED→PENDING resurrection semantics in its existing-row branch.

Client information

Code inspection at main after PR #13365 (ManagedAgentStore.java beginSessionMutation / unarchiveWorkspaceSession; ManagedAgentService.java rename/unarchive admission paths). The window-1 deadlock is reachable with two concurrent same-tenant mutations, no heavy load required.

Anything else we need to know?

• Follow-up to fix(managed-agent): ≥8 concurrent Turns stall after the model answers on modest hardware (lock convoy in the store path) #13333; blocked-by nothing. The deterministic instance (turn-create/submit bursts N−1 deadlock) was fixed in PR fix(managed-agent): stop gap-locked replay probes deadlocking same-tenant admission bursts #13365 with the regression witness HostedConcurrentTurnBurstMySqlIT.
• A fix for window 1 must keep beginSessionMutation's FAILED→PENDING resurrection (ManagedAgentStore.java existing-row branch) reachable — a naive DuplicateKeyException → replayCommand fallback would drop it — and should extend the burst IT with a mutation-burst round rather than inventing a new harness.
• Watch-out: window 2 is a template for what NOT to do — replacing an ON DUPLICATE KEY UPDATE on an existing row with plain INSERT + a FOR UPDATE re-read converts queued losers (exclusive upsert lock) into cross-blocking losers (retained shared lock + lock upgrade). Don't reintroduce that shape.