#22113: feat: support non-image file attachments in webchat chat.send

## Problem Non-image file attachments (PDFs, documents, etc.) sent via WebSocket `chat.send` are silently dropped by `parseMessageWithAttachments()`. This means webchat/WebUI clients cannot send documents for the agent to process, unlike Telegram/Signal channels which save files to disk and pass them through `MediaPath`/`MediaType` context. ## Solution Instead of dropping non-image attachments, collect them as `ChatFileContent`, save to disk via `saveMediaBuffer()`, and populate `MediaPaths`/`MediaTypes` on `MsgContext` — mirroring the existing Telegram/Signal channel behavior. The agent then sees `[media attached: /path/to/file]` in its prompt and can use the Read tool to process file contents. ## Changes - **`chat-attachments.ts`**: New `ChatFileContent` type; `parseMessageWithAttachments` now returns a `files[]` array instead of dropping non-image payloads - **`server-methods/chat.ts`**: Saves file attachments to disk via `saveMediaBuffer`, sets `MediaPaths`/`MediaTypes` on `MsgContext` - **`chat-attachments.test.ts`**: Updated tests for new file collection behavior (all 12 tests pass) ## Backward Compatibility - `ParsedMessageWithImages` type gains an optional-style `files` field; existing consumers that only destructure `images` are unaffected - Image attachment handling is completely unchanged - The `chat.send` schema already accepts `Type.Array(Type.Unknown())` for attachments, so no schema changes needed - Other callers of `parseMessageWithAttachments` (e.g. `server-node-events.ts`) simply ignore the new `files` field <!-- greptile_comment --> <h3>Greptile Summary</h3> Extended WebSocket `chat.send` to handle non-image file attachments (PDFs, documents, etc.) by saving them to disk via `saveMediaBuffer` and populating `MediaPaths`/`MediaTypes` on the message context, mirroring the existing Telegram/Signal channel behavior. The agent now sees `[media attached: /path/to/file]` in its prompt and can use the Read tool to process file contents. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minimal risk. - The implementation correctly extends file attachment handling and maintains backward compatibility. All tests pass, the code follows existing patterns from other channels (Telegram/Signal), and the changes are well-contained. The only concern is the potential for file path conflicts if multiple files have the same name, but this is a minor edge case that the existing `saveMediaBuffer` function already handles via UUIDs. - No files require special attention. _{Last reviewed commit: f852c58} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->