Collapse the six shipped-value-guarded media registry upgraders into one declarative chain

[atomantic]

Problem

server/lib/mediaModels.js now carries at least six registry upgraders that all
share one shape — (id, shippedRepo, priorShippedValue) -> newValue, applied to
a persisted entry only when it still matches what PortOS itself shipped:

• upgradeMiniMaxH3OutputControls (and its nested upgradeMiniMaxH3DenoisingCount)
• upgradeLtx25AudioControls
• upgradeLtx25CudaMemoryFloor
• upgradeLegacyCudaLtxRuntime
• upgradeFastMetalDownloadSizes (added in FastMetal display names understate their download by 3-4x #5871)
• backfillRuntime / dropRetiredEntries at the ends of the same chain

They are composed by hand in normalizeRegistry's videoEntries, which is now
four parens deep and gains a nesting level with every addition:

const normalized = backfillRuntime(upgradeFastMetalDownloadSizes(upgradeLtx25AudioControls(
  upgradeMiniMaxH3OutputControls(dropRetiredEntries(entries)),
)));

The ordering is load-bearing in places (an upgrader must run before
applyVideoDisclosures, which only fills an ABSENT disclosure) but that
constraint is invisible in the expression — it reads as arbitrary nesting.

Work

Introduce an ordered REGISTRY_UPGRADES array reduced in one place, so adding
the seventh upgrader is appending a row rather than adding a paren level. Keep
each upgrader's own guard logic where it is; this is about the composition, not
the rules.

Where an upgrader is a pure (id, shippedRepo, oldValue) -> newValue profile
rewrite (FastMetal and the LTX-2.5 audio backfill both are), consider expressing
it as data plus one shared applier rather than a bespoke function.

Acceptance

• videoEntries composes upgraders from one ordered list, not nested calls.
• Any ordering constraint relative to the apply* decorators is stated in the
  list rather than implied by nesting.
• No behavior change: the existing registry, migration, and disclosure suites
  pass unmodified.

Notes

Raised in review of #5871, which added the sixth upgrader. Deliberately NOT done
in that PR — it touches every upgrader and would have buried a user-facing
download-size fix under a cross-cutting refactor.

Related to #5871

[atomantic]

Shipping in #6134.

Scope decision, recorded here since the issue left it open: the "data plus one shared applier" idea for the pure profile-rewrite upgraders is not done. FastMetal is already data + applier (FASTMETAL_DOWNLOAD_SIZE_PROFILES + upgradeFastMetalEntry); the LTX-2.5 audio backfill guards on revision in addition to id/repo and fills absent keys rather than replacing a shipped value. A single applier covering both would need an optional revision matcher, a nested-object rewrite op, and an absent-key-fill op — abstraction over exactly the guard logic this issue says to leave in place, for two callers. The composition ask (one ordered VIDEO_REGISTRY_UPGRADES list, ordering constraints stated in the list) is delivered.