fix: on restart, serve a video's cached TMDB match instead of re-searching

Root of the 2026-08-29 demo35 storms. `_do_media_meta_request` could not
tell "this is a movie" from "this video isn't enriched yet" — both have
season/episode None — so during a slow initial scan with a browser on the
Videos tab, every show episode requested was run through the *movie*
search path with its raw filename as the query
(`search/movie?query=Show S01E01 1080p WEB DL ...`), hundreds per second,
until TMDB rate-limited and posters stopped loading. Worse, an
un-enriched show episode's own valid cached "tv" match was treated as
stale (its provisional kind was "movie"), so a file already resolved got
re-queried anyway.

- While a video is un-enriched (no display_title — enrich.py always sets
  one), never run a TMDB *search*. Serve the cached match if the content
  hash has one, honouring the cached kind ("tv"/"movie") rather than the
  provisional split; otherwise answer confidence 0.
- Once enriched, the strict `cached_media_type == media_type` check is
  unchanged: an enrichment fix that reclassifies a folder movie->tv still
  drops the stale match and re-resolves.
- video-app.js: `useMediaMeta` gains an `enrichSig` dependency
  (`entry.display_title`) so the client refetches once the enriched fields
  arrive on an index delta — the fileId is a content hash and never
  changes, so nothing else would retrigger it.

Not caused by the V8-V13 work; it raised the per-file call count so the
pre-existing race became a visible storm.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018BMLQjqFGCize2KtNBT79v

0 files changed, 0 insertions, 0 deletions