#18915: fix(telegram): pass video width/height to sendVideo to prevent portra…

## Summary - **Problem:** Telegram's `sendVideo` re-encodes videos when `width`/`height` params are missing, causing portrait (9:16) videos to display distorted/squished - **Why it matters:** Any bot sending portrait video (reels, stories) gets broken display for end users - **What changed:** Added ffprobe dimension probing before `sendVideo`, passes width/height to Telegram API - **What did NOT change:** No new dependencies, no changes to non-Telegram paths, no changes to image/gif/voice sending ## Change Type (select all) - [x] Bug fix ## Scope (select all touched areas) - [x] Integrations ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes Portrait (9:16) videos sent via Telegram bot now display at correct aspect ratio instead of being distorted by Telegram's re-encoding. ## Security Impact (required) - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No - Command/tool execution surface changed? Yes — calls `ffprobe` via `execFile` - Data access scope changed? No - If any Yes, explain risk + mitigation: `ffprobe` is already used by Discord voice messages (`src/discord/voice-message.ts`) via the same `execFile` pattern. Input is piped via stdin from an in-memory Buffer — no temp files, no user-controlled arguments. 5s timeout prevents hangs. Graceful degradation if ffprobe is unavailable. ## Repro + Verification ### Environment - OS: macOS 13.7.8 - Runtime/container: Node 22.22.0 - Model/provider: N/A - Integration/channel: Telegram - Relevant config: Default Telegram bot setup ### Steps 1. Generate or obtain a 720×1280 (9:16) H.264 video 2. Send it via the Telegram bot (agent reply with video attachment) 3. Observe video display in Telegram client ### Expected - Video displays at correct 9:16 portrait ratio ### Actual (before fix) - Video appears squished/distorted — Telegram re-encodes without knowing dimensions ## Evidence - Tested with Kling-generated 720×1280 H.264 Main L31 yuv420p progressive videos - Before: sendVideo without dimensions → distorted display - After: sendVideo with width=720 height=1280 → correct display - Verified ffprobe correctly returns dimensions via pipe:0 stdin ## Human Verification (required) - Verified scenarios: Portrait 9:16 video sent via Telegram bot, confirmed correct display - Edge cases checked: ffprobe unavailable (returns undefined, no crash), non-video media (skipped), video notes (skipped) - What you did not verify: Landscape videos (should work the same), Docker/containerized environments ## Compatibility / Migration - Backward compatible? Yes - Config/env changes? No - Migration needed? No ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert commit `3e48447` — removes 62 added lines, zero existing lines changed - Files/config to restore: `src/telegram/bot/delivery.ts`, `src/telegram/send.ts` (remove probe calls), delete `src/media/video-dimensions.ts` - Known bad symptoms: If ffprobe returns wrong dimensions, video could display at wrong ratio. Mitigation: function returns undefined on any error, falling back to current behavior. ## Risks and Mitigations - Risk: ffprobe not installed in some deployment environments - Mitigation: Graceful degradation — try/catch returns undefined, behavior is identical to current (no dimensions sent). Same risk already accepted for Discord voice messages. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds `ffprobe`-based video dimension probing before calling Telegram's `sendVideo` API to prevent portrait (9:16) video distortion. When Telegram receives a video without `width`/`height` parameters, it re-encodes the video and can distort the aspect ratio. The fix probes dimensions from the in-memory buffer via `ffprobe` stdin piping and passes them to the API. - New `src/media/video-dimensions.ts` utility uses `execFile` + stdin pipe (no temp files, no user-controlled args), with 5s timeout and graceful degradation if `ffprobe` is unavailable - Both Telegram send paths updated: `delivery.ts` (bot replies) and `send.ts` (direct sends), correctly gated to `kind === "video"` only, with `send.ts` additionally excluding video notes - Pattern is consistent with existing `ffprobe` usage in `src/discord/voice-message.ts` - No new dependencies, no changes to non-video media paths <h3>Confidence Score: 4/5</h3> - This PR is safe to merge — it adds a well-isolated, gracefully-degrading feature with no changes to existing behavior paths. - Score of 4 reflects: clean implementation following existing codebase patterns, proper graceful degradation, correct gating logic (video-only, excludes video notes), safe execFile usage with no user-controlled arguments. Minor deduction because probeVideoDimensions is not mocked in the existing test harness (send.test-harness.ts), meaning the video send tests now implicitly depend on ffprobe availability — though they still pass due to graceful degradation. - No files require special attention. All three files are well-implemented. _{Last reviewed commit: 3e48447} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->