#16783: Fix cross-channel routing in iMessage monitor

## Problem When iMessage receives a message in a cross-channel conversation (e.g., Telegram user sending to iMessage contact), agent responses were incorrectly routed to iMessage instead of back to the original channel (Telegram). **Example scenario:** 1. User on Telegram uses message tool to send to iMessage contact 2. Contact replies on iMessage 3. ❌ **Bug**: Agent's response goes to iMessage contact (should go back to Telegram user) 4. ✅ **Fix**: Agent's response now goes back to Telegram user ## Solution This PR fixes the routing by: - Loading the session entry to check for `deliveryContext` - Using `deliveryContext` for `OriginatingChannel`/`OriginatingTo` when present and different from current channel - Falling back to normal iMessage routing when `deliveryContext` is not set **Files changed:** - `src/imessage/monitor/monitor-provider.ts`: Added session loading and deliveryContext check before setting OriginatingChannel ## Testing Tested with Telegram → iMessage → Reply scenario: - ✅ Agent responses correctly route back to Telegram - ✅ Direct iMessage conversations still work normally - ✅ Cross-channel routing respects session deliveryContext ## Notes The same pattern could be applied to other channel monitors (Telegram, Discord, Slack, Signal) if they have similar cross-channel routing issues. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes cross-channel routing in the iMessage monitor so that when a message arrives on iMessage as part of a conversation that originated on another channel (e.g., Telegram), agent replies are routed back to the originating channel rather than being sent via iMessage. - Loads session `deliveryContext` before building the inbound context to detect cross-channel conversations - Overrides `OriginatingChannel` and `OriginatingTo` when the stored delivery context points to a different channel, leveraging the existing `dispatch-from-config` cross-channel routing infrastructure - Falls back to normal iMessage routing when no cross-channel context exists or when the session load fails - Includes an unrelated lockfile cleanup removing `proper-lockfile` from the `extensions/msteams` importer (catching up with a prior package.json change) - No tests were added for the new cross-channel routing behavior in the iMessage monitor — the PR relies on manual testing <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk — it adds a well-guarded read-only check with proper fallback behavior - The change is well-contained (single file with logic changes), uses existing infrastructure correctly (loadSessionStore, deliveryContext, OriginatingChannel pattern), has proper error handling with try/catch fallback, and doesn't modify any existing behavior when no cross-channel context is present. The lack of unit tests is a minor gap offset by the targeted nature of the change and manual testing confirmation. - Pay attention to `src/imessage/monitor/monitor-provider.ts` for potential stale deliveryContext edge cases in long-lived sessions _{Last reviewed commit: 4ff4efb} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->