#23249: fix(message): pass agentId through gateway RPC for media root resolution

## Summary - **Problem:** The \`message\` tool's gateway RPC drops \`agentId\` from the request, causing media file sends for non-default agents to fail with path resolution errors. - **Why it matters:** Users with multi-agent setups cannot send media files from non-default agent workspaces. - **What changed:** Added \`agentId\` to \`SendParamsSchema\`, forwarded it from \`src/infra/outbound/message.ts\` to the gateway, and used it as the preferred agent ID in \`src/gateway/server-methods/send.ts\`. Regenerated protocol files (\`protocol.schema.json\`, Swift \`GatewayModels.swift\`). - **What did NOT change:** Default agent behavior is unchanged. If no \`agentId\` is provided, the existing \`resolveSessionAgentId\` logic applies. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [x] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #23043 ## User-visible / Behavior Changes - Media sends from non-default agents now resolve file paths against the correct agent workspace - No config changes required ## Security Impact (required) - New permissions/capabilities? \`No\` - Secrets/tokens handling changed? \`No\` - New/changed network calls? \`No\` (same RPC, added field) - Command/tool execution surface changed? \`No\` - Data access scope changed? \`No\` — agentId only affects which agent workspace is used for media root resolution, within existing permission boundaries ## Repro + Verification ### Environment - OS: macOS 15.3 (arm64) - Runtime: Node v22+ - Integration/channel: Any channel with media support ### Steps 1. Configure multiple agents with different workspaces 2. Send a media file using the \`message\` tool from a non-default agent 3. Verify the file path resolves against the correct agent workspace ### Expected - Media file is sent successfully from the non-default agent's workspace ### Actual - Before fix: \`agentId\` was dropped, media root resolved against default agent - After fix: \`agentId\` propagates through RPC, correct workspace is used ## Evidence - \`SendParamsSchema\` updated with \`agentId: Type.Optional(Type.String())\` - Protocol files regenerated via \`pnpm protocol:gen && pnpm protocol:gen:swift\` - CI \`protocol:check\` passes after including generated files ## Human Verification (required) - Verified scenarios: Traced agentId flow from \`message.ts\` → \`callMessageGateway\` → \`send.ts\` → \`derivedAgentId\`; confirmed explicit agentId takes priority over session-derived ID - Edge cases checked: Missing/empty agentId falls back to \`resolveSessionAgentId\`; whitespace-only agentId is trimmed and ignored - What I did **not** verify: Live multi-agent media send (no multi-agent setup available) ## Compatibility / Migration - Backward compatible? \`Yes\` — agentId is \`Type.Optional\`, existing callers without it work unchanged - Config/env changes? \`No\` - Migration needed? \`No\` ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the three source files and regenerated protocol files - Files/config to restore: \`src/infra/outbound/message.ts\`, \`src/gateway/server-methods/send.ts\`, \`src/gateway/protocol/schema/agent.ts\`, generated protocol files - Known bad symptoms: If agentId is passed incorrectly, media root could resolve to wrong workspace ## Risks and Mitigations - Risk: An invalid agentId string could cause unexpected workspace resolution - Mitigation: The explicit agentId is only used when non-empty after trim; otherwise falls back to existing logic