fix: address voice-cross-guardian review feedback (5 issues)

[noanflaherty]

Summary

• P1: broadcast/assistantId propagation — Wire setRelayBroadcast in lifecycle.ts and pass { broadcast, assistantId } opts to CallOrchestrator from RelayConnection.handleSetup(), so mac desktop receives guardian_request_thread_created IPC events and multi-assistant deployments use the correct assistant ID.
• P1: bearer auth on guardian deliveries — Thread bearer token through deliverToExternalChannel via readHttpToken() so gateway /deliver/{channel} calls include the Authorization header in secure setups.
• P1: resolve-before-answerCall ordering — In channel-routes guardian answer interception, call answerCall first and only resolveGuardianActionRequest on success. Failed answers leave the request pending for retry from another channel.
• P2: bare JSON string in addMessage — Use content block array format ([{type:'text',text:'...'}]) for addMessage calls in guardian-dispatch.ts and guardian-action-sweep.ts to match codebase convention.
• P2: delivery expiry status filter — Use inArray(['pending','sent']) in expireGuardianActionRequest so deliveries in 'sent' status are also expired (not just 'pending').

Test plan

• Verify mac desktop receives guardian_request_thread_created IPC when a voice call triggers ASK_GUARDIAN
• Verify external channel guardian deliveries include Authorization header
• Verify answering a guardian question after the call's pending question has timed out does not mark the request as resolved
• Verify mac guardian thread messages render correctly (content block array format)
• Verify expiry sweep correctly expires deliveries that were in 'sent' status

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 4 additional findings in Devin Review.

[devin-ai-integration]

🟡 cancelGuardianActionRequest only cancels 'pending' deliveries, missing 'sent' deliveries

The PR correctly fixed expireGuardianActionRequest to use inArray(['pending', 'sent']) so that deliveries already in 'sent' status are expired. However, cancelGuardianActionRequest at guardian-action-store.ts:293-300 has the exact same pre-existing bug that was not fixed: it only cancels deliveries with status = 'pending', leaving deliveries in 'sent' status untouched.

Root Cause and Impact

When a guardian action request is cancelled, cancelGuardianActionRequest updates delivery rows but only those with eq(guardianActionDeliveries.status, 'pending'). In the dispatch flow (guardian-dispatch.ts:139-140), mac deliveries are immediately set to 'sent' via updateDeliveryStatus(delivery.id, 'sent'), and external channel deliveries are set to 'sent' after successful HTTP POST. This means most active deliveries will be in 'sent' status by the time a cancellation occurs.

As a result, cancelling a guardian action request leaves sent deliveries in 'sent' status instead of 'cancelled'. Any logic that checks delivery status to determine if a response should still be accepted would incorrectly treat these as active deliveries. The same reasoning that motivated the inArray(['pending', 'sent']) fix for expireGuardianActionRequest applies equally here.

(Refers to lines 293-300)

---

Was this helpful? React with 👍 or 👎 to provide feedback.