#16785: fix(whatsapp): preserve document filenames in outbound Baileys mode

# fix(whatsapp): preserve document filenames in Baileys mode ## Summary I noticed that whenever we send PDFs or other documents using WhatsApp in Baileys mode, they show up on the recipient's phone as just "file" instead of their actual name. This PR fixes that by ensuring the filename is passed correctly through our outbound pipeline. - **Problem:** Filenames for outbound documents were getting lost between the message tool and the WhatsApp integration. - **Why it matters:** It makes document sharing look broken/unprofessional and makes it hard for users to find what they need in their chat history. - **What changed:** I updated the data flow from the high-level `infra` layer down to the `web/outbound` implementation so that the `fileName` property actually reaches the Baileys logic. - **What did NOT change:** I didn't touch the inbound logic (which was fixed in a previous PR) or how we handle images/videos. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [x] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Related to #15594 (this is the outbound counterpart to that fix) ## User-visible / Behavior Changes None, other than documents now showing their correct names (e.g., `invoice.pdf`) instead of `file`. ## Security Impact (required) None. No new permissions or secrets handling were changed. ## Repro + Verification ### Environment - OS: Linux - Integration/channel: WhatsApp (Baileys) ### Steps 1. Use an agent or the CLI to send a document (e.g., `./openclaw message send --to "whatsapp:..." --media "./my-doc.pdf"`) 2. Check the message on the target phone. ### Expected The file is named `my-doc.pdf`. ### Actual The file is named `file`. ## Evidence I've added a unit test in [src/web/outbound.test.ts](cci:7://file:///home/sahil/open-source/openclaw/src/web/outbound.test.ts:0:0-0:0) called `respects explicit fileName when provided` that mocks the Baileys sender and confirms the `fileName` property is correctly passed into the message object. ## Human Verification (required) - **Verified scenarios:** I traced the code from the tool parameter extraction in [message-action-runner.ts](cci:7://file:///home/sahil/open-source/openclaw/src/infra/outbound/message-action-runner.ts:0:0-0:0) all the way to the [sendMessage](cci:1://file:///home/sahil/open-source/openclaw/src/web/inbound/monitor.ts:368:6-368:94) call in [outbound.ts](cci:7://file:///home/sahil/open-source/openclaw/src/web/outbound.ts:0:0-0:0). - **Edge cases checked:** Verified it still falls back to the detected filename if no name is explicitly provided. ## Compatibility / Migration - Backward compatible? Yes. - Config/env changes? No. ## Failure Recovery (if this breaks) We can just revert the [src/web/outbound.ts](cci:7://file:///home/sahil/open-source/openclaw/src/web/outbound.ts:0:0-0:0) change. The rest of the pipeline changes are safe additions to the parameter objects. ## Risks and Mitigations None. This is a standard metadata propagation fix. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR threads a `fileName` property through the outbound messaging pipeline so that documents sent via WhatsApp (Baileys mode) can preserve their custom filenames instead of showing as generic "file" on the recipient's phone. - Adds `fileName` to `ReplyPayload`, `ChannelOutboundContext`, `MessageSendParams`, and `executeSendAction` params - Extracts `fileName`/`filename` (case-insensitive) from tool parameters in `message-action-runner.ts` - Threads the property through `outbound-send-service.ts` → `message.ts` → `payloads.ts` → `deliver.ts` → WhatsApp outbound adapter → `sendMessageWhatsApp` - In `web/outbound.ts`, prioritizes `options.fileName` over the auto-detected `media.fileName` - Adds a unit test verifying the explicit filename override behavior - **Gap identified:** `fileName` is not forwarded through the gateway RPC path (`callGateway` in `message.ts` and `SendParamsSchema` in `gateway/protocol/schema/agent.ts`). Since WhatsApp uses `deliveryMode: "gateway"`, tool-initiated sends that go through the gateway RPC will not benefit from this fix. The fix does work for auto-reply and direct `deliverOutboundPayloads` call paths. <h3>Confidence Score: 3/5</h3> - This PR is safe to merge — it only adds optional property propagation with no behavioral regressions — but the fix is incomplete for the gateway RPC delivery path that WhatsApp actually uses for tool-initiated sends. - The code changes are clean, well-typed, and include a unit test. The property threading is correct for the direct delivery path and auto-reply flows. However, the gateway RPC path (which WhatsApp uses via deliveryMode: "gateway") does not forward fileName in callGateway params or SendParamsSchema, meaning tool-initiated document sends through the gateway will still lose the custom filename. Score of 3 reflects that the fix is partial — it works for some code paths but not the primary tool-to-WhatsApp gateway flow. - Pay close attention to `src/infra/outbound/message.ts` (lines 217-227) where `fileName` is not forwarded in the `callGateway` params, and `src/gateway/protocol/schema/agent.ts` where `SendParamsSchema` would also need updating. _{Last reviewed commit: e142d03} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->