Description
When sending animated GIFs (as MP4s) using the CLI send command or tools (like skills), the media is sent as a standard video. On mobile WhatsApp clients (iOS/Android), this causes the video to open in a fullscreen player instead of looping inline like a native GIF.

Using gifPlayback: true in the Baileys payload handles this correctly, but currently, the ActiveWebListener stack does not support passing this flag.

Root Cause

1. Interface Limitation: The ActiveWebListener.sendMessage method in src/web/active-listener.ts only accepts (to, text, mediaBuffer, mediaType) and has no parameter for options.
2. Implementation: In src/web/inbound.ts, the sendMessageimplementation constructs the payload but does not check for or set the gifPlayback property.
3. CLI/Outbound: src/web/outbound.ts has no logic to detect if a video file is intended to be a GIF (e.g., via filename convention or explicit flag) and thus never attempts to trigger inline playback.

Repro Steps

1. Download a silent MP4 (e.g. from Tenor).
2. Run clawdis send --to <mobile_number> --media /path/to/animation.mp4 --message "gif test".
3. Result: Message arrives as a video with a play button. Tapping it opens fullscreen.
4. Expected: Message arrives as an auto-looping inline GIF (video with no sound).

Proposed Fix

1. Update ActiveWebListener interface to accept an optional options: { isGif?: boolean } argument.
2. Update src/web/inbound.ts to map options.isGif to the gifPlayback property in the Baileys sendMessage payload.
3. Update src/web/outbound.ts to pass isGif: true if the media filename matches a pattern (e.g. gif_*.mp4) or if explicitly requested.