fix(gateway): scope chat approvals to the active thread

[serrrfirat]

Summary

• scope gateway slash-approve resolution to the active thread so chat approvals cannot resume unrelated background gates
• send approval actions with the approval card thread id instead of always using the currently selected thread
• add backend and e2e regressions for cross-thread slash-approve and wrong-thread approval cards

Verification

• cargo test handle_approval_ignores_pending_gate_from_different_thread --lib
• uv run --project tests/e2e pytest -q tests/e2e/scenarios/test_tool_approval.py -k approval_card_button_posts_card_thread_id\ or\ slash_approve_does_not_intercept_other_thread_card\ or\ slash_approve_is_thread_scoped_api

Fixes #2238

[gemini-code-assist]

Code Review

This pull request implements thread-scoping for tool approvals to ensure that approval actions are correctly associated with their originating conversations. Changes in the frontend ensure that the thread ID is captured from the approval card and passed to the resolution API, while the backend logic was updated to utilize conversation scopes when resolving pending gates for the gateway channel. This prevents commands like /approve from accidentally resolving gates in different threads. The PR also includes comprehensive unit and E2E tests to verify these improvements. I have no feedback to provide as there were no review comments to evaluate.

[henrypark133]

Review: Scope chat approvals to the active thread

Security-positive fix that prevents /approve in thread A from accidentally approving a pending gate in thread B (e.g., a background routine's dangerous tool call). Well-scoped change with proper layering.

Positives:

• Gateway channel gets strict thread scoping via message.conversation_scope(); other channels (Telegram, etc.) keep legacy behavior — no blast radius
• Frontend resolves thread from card's data-thread-id attribute → passed param → currentThreadId fallback chain
• Three-tier test coverage: unit test in router.rs (handle_approval_ignores_pending_gate_from_different_thread), E2E UI test (button posts card's thread_id), E2E API test (test_slash_approve_is_thread_scoped_api)
• The thread_scope variable in handle_approval is clearly documented with the reasoning for gateway-only scoping

Minor notes:

• Cross-PR conflict with #2270: Both PRs modify sendApprovalAction differently — #2267 adds a threadId parameter, #2270 adds a pendingGates Map lookup. They target the same function in crates/ironclaw_gateway/static/app.js. Whichever lands second will need a rebase. The approaches are complementary: #2267's explicit parameter is best for card-initiated actions, #2270's Map lookup is best for tray-initiated actions where no card exists. The reconciled version should use both.

LGTM.

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com