Cache preview frames for Discord video attachments

docs/media-scraper.md

@@ -117,8 +117,11 @@ Downloads run after a finished walk when the scrape used `mode: "download"`:
 
 Previews run after every walk:
 
-- In both modes, Discord-hosted image and GIF URLs (`cdn.discordapp.com`, `media.discordapp.net`)
-  are transformed to the CDN resizer (`media.discordapp.net?...width=320&height=320&format=webp`).
+- In both modes, Discord-hosted image, GIF, and **video** URLs (`cdn.discordapp.com`,
+  `media.discordapp.net`) are transformed to the CDN resizer
+  (`media.discordapp.net?...width=320&height=320&format=webp`). The proxy renders a frame for
+  video files, so attachment mp4/webm get a cached poster in links mode without downloading the
+  file. Download mode additionally keeps an ffmpeg poster.
 - In both modes, embed rows also get their stored `preview_url` (YouTube, X, TikTok thumbnails,
   and so on) cached. The embed's full media URL is never fetched; embed rows are excluded from
   `pendingDownloads`.

docs/media.md

@@ -90,8 +90,9 @@ media-scrape/db/
   owns that path.
 - Third-party embeds are **never downloaded as media**: YouTube, Instagram, X, TikTok, and every
   other embed stays a link. Its thumbnail is cached (below); the video itself is never fetched.
-- Previews are cached in `thumbs/` after every walk, in both modes: Discord-hosted images and GIFs
-  (resized to 320px WebP) and third-party embed thumbnails (YouTube, X, TikTok, and so on). The
+- Previews are cached in `thumbs/` after every walk, in both modes: Discord-hosted images, GIFs,
+  and video files (the proxy renders a frame, resized to 320px WebP) plus third-party embed
+  thumbnails (YouTube, X, TikTok, and so on). The
   stored bytes keep their real type (`preview_ext`), so JPEG provider thumbnails are served as
   `image/jpeg`, not mislabeled WebP. Embeds without a thumbnail in Discord's data are resolved
   through the provider's oEmbed/fxtwitter API and finally the page's `og:image`. Previews count