refactor: compose the video registry upgraders from one ordered list (#6056)

[atomantic]

Summary

normalizeRegistry's videoEntries composed six load-time registry upgraders by hand — four parens deep, plus a conditionally-applied pair for the CUDA bucket driven by an upgradeLegacyCudaLtx flag. Every upgrader added since has cost a nesting level, and the ordering (which is load-bearing) read as arbitrary nesting.

This replaces the nest with an ordered VIDEO_REGISTRY_UPGRADES list reduced in one place:

• Each row names its upgrader and states its ordering constraint beside it, instead of the constraint being implied by nesting depth. The two that matter: upgradeFastMetalDownloadSizes must precede applyVideoDisclosures (that decorator only fills an absent disclosure, so a stale persisted estimatedDownloadGb has to be corrected before it), and dropRetiredEntries must run first so a withdrawn model is not handed a disclosure / Finish edge / speed profile / draft decoder on its way out.
• A buckets field on a row replaces the upgradeLegacyCudaLtx boolean for the two CUDA-only upgraders.
• Adding the seventh upgrader is appending a row.

Behavior preservation

This is a pure composition change — no upgrader's rules were touched:

upgrader	guard	before	after
dropRetiredEntries	id in RETIRED_VIDEO_MODELS and repo === shippedRepo	1st, all buckets	1st, all buckets
upgradeMiniMaxH3OutputControls (+ nested …DenoisingCount)	id + shipped repo, per-field shipped-value match	2nd	2nd
upgradeLtx25AudioControls	id + repo + revision, absent keys only	3rd	3rd
upgradeFastMetalDownloadSizes	id + shipped repo, oldName / oldEstimatedDownloadGb exact match	4th	4th
backfillRuntime	LEGACY_MLX_VIDEO_IDS, only when runtime unset	5th	5th
upgradeLegacyCudaLtxRuntime	ltx_video, no repo, runtime unset/mlx_video	6th, bucket === 'cuda'	6th, buckets: ['cuda']
upgradeLtx25CudaMemoryFloor	id + repo + minMemoryGb === 32	7th, bucket === 'cuda'	7th, buckets: ['cuda']

The upgraders the registry migrations import (upgradeMiniMaxH3OutputControls, upgradeMiniMaxH3DenoisingCount, upgradeFastMetalDownloadSizes, upgradeLtx25CudaMemoryFloor) keep their exports and signatures, so migrations 267 / 271 / 336 are unaffected — no compatibility or upgrade path is removed.

Scope note

The issue also floated folding the pure (id, shippedRepo, oldValue) -> newValue upgraders into "data plus one shared applier". Not done, deliberately: FastMetal is already data + applier (FASTMETAL_DOWNLOAD_SIZE_PROFILES + upgradeFastMetalEntry), while the LTX-2.5 audio backfill guards on revision as well and does absent-key filling rather than shipped-value replacement. One applier covering both would need an optional revision matcher, a nested-object rewrite op, and an absent-key-fill op for two callers — a speculative abstraction over the exact guard logic the issue says to leave alone. Left as-is.

Test plan

• Two new guards in server/lib/mediaModels.test.js:
  • the chain order is pinned by name via a new VIDEO_REGISTRY_UPGRADE_NAMES export, so a reorder is a deliberate two-file edit rather than a silently-shipped behavior change;
  • the CUDA-only rows are asserted not to reach the MLX bucket (verified failing — expected 'cuda_video' to be undefined — with the buckets gate removed).
• server/lib/mediaModels.test.js + server/lib/index.test.js: 87 passed.
• Full server suite: 38717 passed / 1915 files. Two unrelated 10s timeouts under parallel load (routes/settings.secretsStrip.test.js, services/voice/facetimeBridge.test.js — the latter compiles a Swift helper); both pass in isolation and neither touches this code.

Closes #6056

https://claude.ai/code/session_01RA3pD5YM2dukQwbZ3pC6WA