Group chats: report why a promised video never arrived

[miridius]

Problem

In a group chat, a failing video link produces nothing at all: the bot identifies the video, fails to deliver it, and stays silent, so the requester never learns why their mp4 didn't arrive (#17). Separately, links that aren't videos at all (an Instagram photo post, a Reddit text post) burned the full 3-attempt retry budget on a deterministic error, filling private chats with retry notices for a failure no retry can fix (#14).

Fix

A group now gets exactly one terminal failure line, replying to the link message and worded like the private-chat one, when all of these hold:

• the failure is terminal (permanent, or the last attempt), and
• it is not a "not-a-video" error, and
• either the metadata scrape had already proven a real video, or the link's host is on the always-expect-a-response list (instagram.com, reddit.com, redd.it).

Every other group case stays silent as before, each pinned by a test: not-a-video errors (photo/text posts) on any host, scrape failures on non-listed hosts, too-large verdicts, and silence through transient retries.

Underneath, yt-dlp failures now classify three ways (not-a-video / unavailable / transient) from their stderr ERROR: lines, with each not-a-video pattern pinned to its extractor tag; the patterns were verified against real yt-dlp output ("No media found" also exists untagged in the f4m downloader, which must stay retryable). Not-a-video is deterministic, so those failures take one attempt instead of three.

Tests: pinning unit tests for every silence rule and both report rules; two e2e cases drive the group seam end to end against real yt-dlp (a photo post staying silent, a dead reel producing the single report), with the e2e mock extended to support group chats.

Settled design decisions

• The group gate is failure-source-agnostic: a terminal send failure also leaves the requester with no video, so it earns the same line (pinned by comment + test).
• Too-large verdicts stay silent in groups.
• The always-respond hosts are a deliberate flat list chosen in the design discussion; scrape failures on other hosts stay silent because a scrape failure can't distinguish a video from an article. Extending the set is a one-line change.

Closes #17. Closes #14.