#23333: fix(matrix): add accountId routing for multi-account message sending 🤖

## Summary - **Problem:** Matrix channels with multiple accounts incorrectly used the default/first authenticated account when sending images, instead of the account bound to the agent. - **Why it matters:** Multi-account Matrix setups would fail to send media from non-default accounts due to wrong account routing. - **What changed:** Added `accountId` propagation through the message tool chain (Matrix actions → tool handlers → threading context → message-action-runner). - **What did NOT change:** No changes to auth, config schema, or other channels. ## Change Type - [x] Bug fix ## Scope - [x] Integrations ## Linked Issue/PR - Related # (add if there's an existing issue) ## User-visible / Behavior Changes - Matrix multi-account setups now correctly route outbound messages/media through the account bound to each agent. ## Security Impact - New permissions/capabilities? `No` - Secrets/tokens handling changed? `No` - New/changed network calls? `No` - Command/tool execution surface changed? `No` - Data access scope changed? `No` ## Repro + Verification ### Environment - OS: Debian Linux - Runtime: Node 22+ - Integration/channel: Matrix ### Steps 1. Configure Matrix channel with 2 accounts (`default` and `muse`) 2. Bind `main` agent → `default` account, `muse` agent → `muse` account 3. Send image via `muse` agent in its Matrix DM ### Expected - Image sends successfully using the `muse` account ### Actual (before fix) - System attempted to send with `default` account, failing because that account isn't in the DM ### Actual (after fix) - Image sends correctly using the `muse` account ## Evidence - [x] Tested manually with multi-account Matrix setup ## Human Verification - Verified scenarios: Both accounts can send messages and images in their respective DMs - Edge cases checked: Private DM channels for each account - What you did NOT verify: Group rooms, other media types ## Compatibility / Migration - Backward compatible? `Yes` - Config/env changes? `No` - Migration needed? `No` ## Failure Recovery - How to disable/revert: Revert commit - Known bad symptoms: None expected ## Risks and Mitigations - Risk: None - additive change only adds optional accountId parameter - Mitigation: N/A --- ## AI Assistance Disclosure 🤖 **AI-assisted:** This PR was developed with AI assistance. - **Degree of testing:** Fully tested - manual testing with live Matrix multi-account setup - **AI tools used:** Kline+GLM-5 for diagnosis and commit preparation (10M tokens) - **Understanding confirmation:** I understand what this code does - it threads `accountId` through the Matrix message sending pipeline so that multi-account setups route outbound messages through the correct account instead of always using the default/first authenticated account. <!-- greptile_comment --> <h3>Greptile Summary</h3> Added `accountId` propagation through Matrix message sending pipeline to fix multi-account routing. When multiple Matrix accounts are configured and bound to different agents, outbound messages (especially media) now correctly route through the agent's bound account instead of defaulting to the first authenticated account. **Key changes:** - Threads `accountId` from `ChannelMessageActionContext` through Matrix actions, tool handlers, and message runner - Adds `currentAccountId` field to `ChannelThreadingToolContext` type with JSDoc - Routes `accountId` from HTTP headers (`x-openclaw-message-to`) to tool context in gateway - Falls back to `toolContext.currentAccountId` before `defaultAccountId` in message action runner **What works:** - The implementation correctly propagates `accountId` through all layers for send action - Maintains backward compatibility with optional parameters - Follows existing multi-account patterns established in commit 2b685b08 - Type definitions are properly updated with documentation **Incomplete coverage:** - Other Matrix actions (react, edit, delete, read, pin, unpin, etc.) don't receive `ctx.accountId` from the action adapter in `extensions/matrix/src/actions.ts:86-192`, though they accept it via `MatrixActionClientOpts`. This means these actions may still route to wrong accounts in multi-account setups. <h3>Confidence Score: 4/5</h3> - Safe to merge - focused bug fix with proper typing and backward compatibility - The implementation correctly threads `accountId` through the Matrix message sending pipeline. All changes are additive (optional parameters), maintaining backward compatibility. The code follows established patterns from previous multi-account fixes. Score is 4 (not 5) because other Matrix actions could have the same routing issue but aren't addressed in this PR. - No files require special attention - all changes are straightforward parameter additions _{Last reviewed commit: 4977888} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->