Fix local Oz run_agents child rendering as duplicate local + remote pills

[warp-agent-staging]

Description

One local run_agents dispatch (local: {}, single child, default Oz harness) could render two orchestration pills for the same server run — one local, one remote-flagged — while the server had only one child run and one conversation. The identical omission existed in the TUI front-end, filed as QUALITY-1902 and fixed here too.

Root cause, in both front-ends (warp-server's EventChildAgentStarted emission for local children is correct and untouched): the local-Oz child launch path stamped the child's task id with a bare conversation.set_task_id(...), which never updates the agent_id_to_conversation_id index — the only idempotency key the SSE remote-child-placeholder path (ensure_remote_child_placeholder / finish_remote_child_placeholder) checks. Whichever of the two async paths — the local launch's own callback, or the SSE placeholder's task-metadata fetch — resolved second created a duplicate, remote-flagged conversation for the same run id.

Changes

The fix closes both race orderings with two changes:

1. Index the run id at launch. Both local launch paths now call assign_run_id_for_conversation instead of the bare set_task_id:
   • GUI: launch_local_no_harness_child (app/src/pane_group/pane/terminal_pane.rs) via a new shared helper, finish_local_oz_child_conversation (app/src/ai/blocklist/child_agent_launch.rs).
   • TUI: register_local_oz_child_session (crates/warp_tui/src/orchestration_model.rs) calls the same shared helper, re-exported via tui_export.rs.
2. Reconcile a raced placeholder inside the index writer itself. assign_run_id_for_conversation (app/src/ai/blocklist/history_model.rs) now checks whether the run id is already mapped to a different conversation; if that conversation is_remote_child(), it's a stale SSE placeholder and gets discarded (discard_stale_placeholder_for_run_id); otherwise the mismatch is logged rather than silently deleted, since that would indicate an unrelated bug. Credit: this centralized, placeholder-gated design is adopted from Matthew Albright's independent fix in #15584, including its regression test.

(1) alone would still leave the reverse race open (SSE placeholder wins first); (2) alone is unreachable on the no-harness path, since a launch path that never calls assign_run_id_for_conversation never reaches the guard, and the SSE path's own pre-existing idempotency check (conversation_id_for_agent_id) never resolves either, since the run id was never indexed. Both are required together.

The TUI's tab bar does not currently render the resulting duplicate conversation (TuiOrchestrationModel::snapshot filters children by TUI session presence, and a placeholder has no session), so this closes a latent data-model inconsistency there rather than an observed visible symptom.

Known remaining gap, not fixed here: initialize_output_for_response_stream (history_model.rs, ~1504) also writes agent_id_to_conversation_id directly and doesn't go through the new guard. For this fix's case that's harmless (assign_run_id_for_conversation already runs first, at launch time), but it's an architecturally unguarded writer of the same index for other call paths. Filed as follow-up hardening: QUALITY-1911.

Linked Issue

Fixes QUALITY-1897 and QUALITY-1902.

• Diagnosis and fix direction were provided directly on the issue.
• Visual verification captured for the GUI flow — see below.

Testing

• local_oz_launch_indexes_run_id_before_child_agent_started_sse (GUI, orchestration_event_streamer_tests.rs) — drives finish_local_oz_child_conversation directly (the exact call launch_local_no_harness_child makes), so a regression there fails the test.
• sse_placeholder_then_local_launch_converges_on_one_conversation (GUI) — SSE placeholder created first, then the local launch reclaims the run id through the guard; asserts exactly one conversation survives.
• primary_placeholder_still_created_for_out_of_band_local_children (GUI) — an out-of-band LOCAL child (dispatched via CLI/API on another device) still gets a placeholder, guarding against over-broadly suppressing legitimate placeholders.
• assign_run_id_for_conversation_discards_stale_remote_placeholder_for_same_run_id (GUI, adopted from Fix duplicate orchestration pills for local child agents #15584) — unit coverage for the guard itself.
• local_oz_child_session_indexes_run_id_immediately (TUI, orchestration_model_tests.rs) — drives register_local_oz_child_session itself with a real MaterializedLocalOzChildSession, so a regression at that call site fails the test.

Each of the tests above that targets a specific call site was verified by reverting that production line, confirming the test failed, then restoring it.

Ran:

• cargo nextest run -p warp (full package): 6257/6260 passed. The 3 failures (missing nsc tool; a multibyte-decoration test; a zsh histignorespace test) are pre-existing on master too (confirmed via git stash + re-run), unrelated to this change.
• cargo nextest run -p warp_tui -p warp --lib -E 'package(warp_tui) and test(orchestration_model)': 22/22 passed. (Building warp_tui in full isolation hits a pre-existing, unrelated warpui platform-delegate compile gap under the test-util feature; building it alongside warp resolves features the way the real workspace build does and avoids it.)
• ./script/format and cargo clippy -p warp --all-targets --all-features --tests -- -D warnings / cargo clippy -p warp_tui -p warp --lib --tests -- -D warnings — clean, no new diagnostics.

Visual verification

This is a background race, not reachable through a deterministic manual repro. A delegated computer-use session built this branch, launched the real Warp GUI, and drove an actual run_agents(local: {...}) dispatch end to end. Result: exactly one pill rendered for the local child, labeled correctly as local, ran to completion.

• Video (prompt → confirmation → pill appears → completes): https://oz.staging.warp.dev/artifacts/01a03fe2-ed02-79fd-8271-e8ea36a006c1
• Screenshot (full window, pill bar + transcript): https://oz.staging.warp.dev/artifacts/01a03fe3-5b17-713e-bfa6-6a8e61a422dc
• Screenshot (zoomed pill bar, final state): https://oz.staging.warp.dev/artifacts/01a03fe3-8d67-7871-acda-31aae9ae4fd9

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed a race that could make a single local Oz run_agents child appear as two orchestration pills.

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.

  

[warp-local-for-testing-only]

An unexpected error has occurred: managed MCP server 01a01a21-3ec9-71a1-99f2-f13b1773c920 is not active