fix(gateway): resolve assistant thread for threadless broadcasts

[standardtoaster]

Problem

Mission notifications, self-repair alerts, and extension activation messages broadcast via channels without a thread_id. The gateway's broadcast() rejects these with MissingRoutingTarget, silently dropping the messages.

Root cause

The gateway requires thread_id for SSE routing (added in the no-silent-drop hardening). Three callers send without one:

• src/bridge/router.rs:2933 — mission notifications (thread_id available but not passed)
• src/extensions/manager.rs:6849 — Telegram owner verification (no thread context)
• src/agent/agent_loop.rs:752,765 — self-repair notifications (no thread context)

Note: the heartbeat path (src/agent/heartbeat.rs:416) already resolves a thread_id via get_or_create_heartbeat_conversation before sending, so it is NOT affected.

Fix

1. Mission notification now chains .in_thread(notif.thread_id.to_string()). The thread_id was already on MissionNotification — the SSE broadcast 3 lines below was using it.

2. Gateway broadcast() falls back to the user's assistant conversation (via get_or_create_assistant_conversation) when thread_id is None. This routes threadless messages to the assistant thread instead of rejecting them. When no DB store is available, the original MissingRoutingTarget error is preserved.

Test plan

• cargo clippy --all — zero warnings
• cargo test -- no_silent_drop — 5 tests pass:
  • gateway_broadcast_without_thread_id_and_no_store_returns_error — no store = error (renamed)
  • gateway_broadcast_with_thread_id_succeeds — unchanged
  • gateway_broadcast_without_thread_id_falls_back_to_assistant_thread — new (libsql): creates a gateway with a real DB store, broadcasts without thread_id, verifies success via assistant thread fallback
  • gateway_respond_without_thread_id_returns_error — unchanged
  • gateway_respond_with_thread_id_succeeds — unchanged

Local verification attempted: Started IronClaw locally with Qwen on MLX, but the three affected callers (missions, self-repair, extension activation) are difficult to trigger in a minimal setup. The heartbeat fires successfully but uses its own thread_id resolution and doesn't exercise the broken path. The unit test exercises the exact broadcast() method with a real libsql-backed gateway, which is the code path all three callers share.

• Staging: fire a mission with notify_channels: ["gateway"] and verify the notification appears in the assistant thread

Fixes #2405

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[serrrfirat]

Paranoid Security Review — NEEDS CHANGES

PR: #2444 — Resolve assistant thread for threadless broadcasts
Reviewer context: Automated deep security review

Medium

Cross-user thread ID leakage in mission notification path. In src/bridge/router.rs:2930-2935, the PR adds .in_thread(notif.thread_id.to_string()) to the broadcast. However, broadcast_user can be notif.notify_user — a different user than the mission owner. The notif.thread_id belongs to the mission owner's thread. When notify_user is set, the broadcast sends the owner's thread_id to a different user's context.

Fix: When notify_user.is_some() and differs from user_id, do NOT attach notif.thread_id. Let the gateway's broadcast() fallback resolve the recipient's own assistant thread instead.

Low

• TOCTOU race in get_or_create_assistant_conversation (pre-existing): Non-transactional SELECT-then-INSERT. Two concurrent broadcasts could create duplicate assistant threads on PostgreSQL. The INSERT lacks ON CONFLICT. Fine as a follow-up.

Positive

• No cross-user thread access vulnerability in the fallback path — user_id flows from server-side callers, not client input.
• No .unwrap() or .expect() in production code.
• Test coverage is solid with a real libSQL backend.

Summary

The fallback design is sound and well-tested. The mission notification thread_id mismatch is the only blocking issue — straightforward to fix by conditionally attaching the thread_id only when the broadcast target matches the thread owner.

[serrrfirat]

Medium Severity — Test doesn't verify the resolved thread_id

The new test asserts result.is_ok() but doesn't verify that the message was actually routed to the correct assistant thread. A regression where the fallback "succeeds" but uses a wrong or stale thread_id would pass this test.

Suggestion: Subscribe to gw.state.sse before calling broadcast(), receive the emitted AppEvent::Response, and assert its thread_id matches the UUID returned by get_or_create_assistant_conversation("test-user", "gateway"). Also query the DB to verify the conversation row exists.

[serrrfirat]

Medium Severity — No test for the cross-user thread_id guard

The if broadcast_user == notif.user_id condition is a security-sensitive guard that prevents leaking the owner's mission thread_id to a different recipient. Per .claude/rules/testing.md ("Test Through the Caller"), when a predicate gates a side effect with computed inputs, a caller-level test is required.

Suggestion: Add an integration test that exercises handle_mission_notification (or the broadcast path) with a MissionNotification where notify_user = Some("other-user"), and verify the response sent to the channel does NOT carry the owner's thread_id. Separately test the notify_user == None case to verify thread_id IS attached.

[serrrfirat]

Approving — the fix is correct and well-scoped. The cross-user thread_id guard and the gateway fallback are both sound.

Follow-up request: Please address the two inline comments about test coverage in a subsequent PR:

1. Verify the resolved thread_id in the fallback test — subscribe to SSE, assert the emitted thread_id matches the assistant conversation UUID, and confirm the DB row exists.
2. Add a caller-level test for the cross-user guard — exercise handle_mission_notification with notify_user = Some("other-user") and verify the response does NOT carry the owner's thread_id.

These are Medium-severity gaps (security-sensitive condition + fallback correctness) but the code itself is correct, so they shouldn't block merge.

[serrrfirat]

I prefer this solution to the problem because it addresses the root cause.

[serrrfirat]

LGTM — the cross-user thread_id guard and DB fallback are both correct and well-tested.

Follow-up items from security review

A few pre-existing issues that this PR doesn't introduce but does increase exposure to:

1. TOCTOU race in get_or_create_assistant_conversation (CRITICAL, pre-existing): Both backends use SELECT-then-INSERT without a transaction or unique constraint. Compare with the heartbeat path (store.rs:1997) which correctly uses ON CONFLICT DO NOTHING. With the DB fallback now being the hot path for all threadless broadcasts, concurrent calls can create duplicate assistant conversations. Tracked in a follow-up issue.

2. Direct SSE broadcast bypasses cross-user guard (MEDIUM, pre-existing): router.rs:2947 always sends to notif.user_id with the owner's thread_id, even when notify_user routes to a different recipient. The channel broadcast path (this PR) respects the guard, but the direct SSE path doesn't.

3. notify_user is unvalidated LLM-derived input (MEDIUM, pre-existing): effect_adapter.rs:1206 accepts arbitrary user strings from tool params without checking the user exists or the caller has permission to notify them.

None of these block merge — they're all pre-existing and the PR is well-scoped.

[serrrfirat]

CI is green now. Re-approving after fixing:

1. rustfmt: Collapsed handle_mission_notification call sites to single-line form in the cross-user guard tests
2. cargo-deny: Added RUSTSEC-2026-0098 exception for rustls-webpki 0.102.8 (pinned by libsql transitive dep, same chain as existing RUSTSEC-2026-0049 exception) and bumped 0.103.10 → 0.103.12

Follow-up items tracked in #2488.