feat(gui,fuse,core): video thumbnails in file views

My files, Shared, Trash and the launcher now ask the daemon for video
thumbnails, not only image ones. Grid tiles with a video thumbnail show
a small play badge.

A `.ts` file is a video from 1 MiB up and a TypeScript source below
that. One rule in pdfs-core (`is_video_file_name`) decides it for the
file icon, the thumbnail gate, the launcher icon and preview, and the
opener's `@media` / `@text` classes. The daemon also checks the MPEG-TS
sync byte before it runs ffmpeg, so a large TypeScript bundle gets no
retries.

A video thumbnail no longer downloads the whole file into memory (B283):
- the server thumbnail is tried first, at no content cost;
- files up to 24 MiB come whole;
- larger ones bring a 16 MiB head, plus the MP4/MOV `moov` box when it
  lies past the head, into a sparse staging file that ffmpeg reads.
The 256 MiB cap is gone. Without ffmpeg, a video answers "no thumbnail"
at once. The folder thumbnail build includes videos.

docs/BUGS.md

@@ -109,6 +109,7 @@ a live account since.
 
 | Entry | Title |
 |---|---|
+| [B283](#b283--videos-have-no-thumbnail-outside-photos-and-a-ts-recording-looks-like-source-code) | Videos have no thumbnail outside Photos, and a `.ts` recording looks like source code |
 | [B280](#b280--uploading-a-batch-of-large-photos-swaps-the-machine-until-the-daemon-is-killed) | Uploading a batch of large photos swaps the machine until the daemon is killed |
 | [B279](#b279--after-a-watchdog-kill-the-mount-never-comes-back) | After a watchdog kill the mount never comes back |
 | [B278](#b278--sync-list-and-devices-list-show-the-last-sync-as-epoch-seconds) | `sync list` and `devices list` show the last sync as epoch seconds |
@@ -383,6 +384,51 @@ a live account since.
 
 Newest first.
 
+### B283 — Videos have no thumbnail outside Photos, and a `.ts` recording looks like source code
+
+**Status:** Fixed, not verified live
+**Found:** 2026-11-14, from a user report: large `.ts` video recordings in My files showed a text
+icon, and no video in My files had a thumbnail although the same videos had one in Photos.
+**Where:** `is_video_file_name` in `crates/pdfs-core/src/control.rs`; `generate_thumbs` and
+`sample_video` in `crates/pdfs-fuse/src/photos.rs`; `bind_file_thumbnail` in
+`crates/pdfs-gui/src/app/widgets/thumbnails.rs`
+
+**Repro:** Put an `.mp4` and a recorded `.ts` of a few GB in My files and open the folder in the
+app's grid view. Both show a generic icon, and the `.ts` shows a text one.
+
+**Cause.** Four things:
+- File views asked the daemon for thumbnails of images only (`is_thumbnail_image_name`), so a
+  video was never asked for.
+- `.ts` is TypeScript as often as it is an MPEG transport stream. Drive stores both as
+  `application/octet-stream`, and every place that names a file's type went by the extension:
+  the browser's icon list had no `.ts`, GIO guesses text, and the opener's `@text` class listed
+  `.ts`.
+- The daemon downloaded a video whole into memory for one frame, so it refused anything over
+  256 MiB, and the size check behind that refusal asked the Photos client, which knows nothing
+  of a My files node.
+- `file_thumbs` never asked for the thumbnail an uploader attached, on the belief that only
+  Photos nodes have one. This client attaches one to every upload it can make one for.
+
+**Fix.** `is_video_file_name(name, size)` is the one rule: a video extension, and for `.ts` a
+size of at least 1 MiB. The browser icon, the thumbnail gate, the launcher's icon and type, and
+the opener's classes use it. For a file view, the daemon first asks Drive for the file's own
+thumbnail. Without one, a video of up to 24 MiB is downloaded whole. A larger one brings its first
+16 MiB, and for an MP4 or MOV whose `moov` box lies further in, the box headers on the way and
+that box. The parts are laid out at their offsets in a sparse staging file, which ffmpeg reads.
+A `.ts` whose head lacks the 0x47 sync byte is recorded as having no thumbnail.
+
+**Test:** `a_ts_file_is_a_video_only_at_the_size_of_one` and
+`listings_thumbnail_images_and_videos` in `crates/pdfs-core/src/control.rs`;
+`a_ts_file_opens_as_media_or_text_by_its_size` in `crates/pdfs-core/src/opener.rs`;
+`a_large_mp4_downloads_its_head_and_its_index` and the other `sample_video` tests in
+`crates/pdfs-fuse/src/photos.rs`; the simulation
+`a_video_thumbnail_downloads_a_small_part_of_the_video`, which reads under 34 MiB for two
+videos of over 70 MiB and takes nothing from a video with an uploader's thumbnail.
+`real_video_fixture_yields_a_frame` passed on 2026-11-14 with ffmpeg 9.0 for a 46 MB MP4 with its
+index at the end, an MPEG-TS and an MKV.
+
+---
+
 ### B280 — Uploading a batch of large photos swaps the machine until the daemon is killed
 
 **Status:** Fixed, not verified live

docs/CHANGELOG.md

@@ -32,6 +32,20 @@ Existing folders remain device backups; older builds cannot open the upgraded da
   My files folder. The first sync preserves one-sided files and differing versions (#67).
   Attachments stay in mirror mode, are excluded from device profiles, and cannot delete
   the remote root when syncing is stopped.
+- **Video thumbnails in My files, Shared, Trash and the launcher**, as in Photos, with a play
+  badge in the grid. A video's thumbnail is the one its uploader attached when it has one.
+  Otherwise the daemon takes a frame with ffmpeg from the start of the file, plus an MP4's
+  index, and never downloads more than about 16 MiB of a video for it, however large the
+  video is. **Build Thumbnails** covers videos too (B283).
+
+### Fixed
+
+- Large `.ts` recordings (MPEG transport streams) show and open as videos: the video icon, a
+  thumbnail, and the `@media` open rule rather than `@text`. A `.ts` of 1 MiB or more counts
+  as a video, a smaller one stays TypeScript source, and the daemon checks the stream's sync
+  byte before it takes a frame (B283).
+- A video over 256 MiB never got a thumbnail, and a smaller one was downloaded whole into
+  memory for one frame (B283).
 
 ## [3.7.0] — 2026-11-02