feat(node,hub): add Videos group app (poster grid, flat list, TMDB metadata)

Implements docs/mediacenter.md: a "Videos" group application built on the
existing files index rather than a separate catalogue. On the node side,
new indexer enrichment (technical probe, filename/season parsing, thumbnail
generation) runs per-file once an operator has chosen a video_root for the
group, plus a TMDB client for on-demand poster/metadata lookups (never
client-side, thumbnails delivered over the existing chunk path). On the hub
side, a new video-app.js renders a lazily-mounted poster grid or a
thumbnail-only flat list, with TMDB entirely optional per group.

Along the way: the global apps registry now drives Settings' default-tab
picker instead of a hardcoded list, and the video_root is configured from
group Settings (like uploads) rather than from Files, with the node
refusing to run any TMDB/thumbnail work until one is set.

Fixes several bugs found via live testing against a real library, notably
a race between two effects writing the same "image ready" state that could
leave a poster grid spinning forever on a same-tab revisit — see
mediacenter.md §5.4 for the full account of each one.

1 files changed, 19 insertions, 13 deletions

diff --git a/docs/apps.md b/docs/apps.md
index 94116c6..931114d 100644
--- a/docs/apps.md
+++ b/docs/apps.md
@@ -6,7 +6,7 @@
 > document is the how-to.
 
 A group has "applications" — Chat and Files today, Videos/Music/Photos planned
-(Netflix-style browsing, Spotify-style playback, an album viewer). None of the
+(a poster-grid browser, a music player, an album viewer). None of the
 planned ones need an MNP protocol change: video/audio/image files are already
 classified by the node's indexer (`meshbay_node/indexer/indexer.py`, `type:
 video|audio|image`) and flow through the same `index_sync`/`file_req`/
@@ -172,18 +172,24 @@ the only node-side touches, and both are allow-lists, not new wire messages.
 
 ## 5. What does not exist yet
 
-- **Thumbnails/posters.** No generation mechanism, client or node side. A
-  Netflix-style grid or a photo album needs *something* here; the pragmatic
-  v1 (decided but not built) is lazy, client-side: decrypt the image, or a
-  video's first segment, only for tiles actually visible, with an in-memory
-  cache — no new MNP message, no node-side store. This is real per-tile cost
-  (a full chunk-pipelined decrypt per thumbnail), acceptable for a browsing
-  grid, not for hundreds of tiles rendered at once — a virtualized grid is
-  part of building Videos/Photos, not optional.
-- **Videos, Music, Photos themselves.** Deliberately out of scope for the
-  refactor that built this — see `meshbay-draft-v6.md` §2.7. The
-  infrastructure above is proven end-to-end with the two apps that already
-  existed (Chat, Files); a new one is additive.
+- **Thumbnails/posters — built for Videos, 2026-08-23, see `docs/mediacenter.md`.**
+  The plan below (lazy, client-side, no node-side store) turned out to be
+  wrong once a real design pass ran the numbers: `docs/mediacenter.md` §2
+  revises `desktop-client-v1.md`'s O12 and has the node generate thumbnails
+  (an `ffmpeg` frame grab, its own bounded worker pool) and cache them
+  durably in its own `data_dir`, delivered over the existing `file_req`/
+  chunk path addressed by their own blake3 hash. TMDB posters/metadata are
+  fetched and cached by the node the same way — no client ever talks to
+  TMDB directly. A virtualized grid (`IntersectionObserver`-based lazy
+  mount) is built in `video-app.js`, per the note below. A future Photos
+  app can reuse the same node-side machinery (thumbnail cache, chunk-path
+  delivery) without re-deciding any of this.
+- **Videos, Music, Photos themselves.** Videos is now built (`video-app.js`,
+  `docs/mediacenter.md`). Music and Photos remain deliberately out of scope
+  — see `meshbay-draft-v6.md` §2.7. The infrastructure in this document was
+  proven end-to-end first with Chat/Files, then with Videos; Music/Photos
+  are additive from here, and can reuse Videos' thumbnail/chunk-delivery
+  machinery rather than re-deciding it.
 - **The offline/loopback settings path.** `member_upload` can be toggled two
   ways: over a live MNP connection, or (Electron only) via the node's local
   HTTP API when MNP isn't connected (`platform.node.call('PUT', .../member-