[cre8ive-marketing]

Fixes #485.

@KnifeLemon, could you review this for merging into main? If you had already started on it, feel free to close this one.

What it does

.usm (CRI Middleware's video container, used for many games' cutscenes) becomes a read-only video source, like WTV, RM or CAVS:

• FormatRegistry: usm, category Video, Writable: false.
• It shows up on the video donut and goes to MP4 and every other video and audio target through FFmpeg, which Filee bundles (9.0.2 has the usm demuxer: ffmpeg -demuxers lists usm CRI USM).
• It's never a target, so there's no USM writer.
• Encrypted USM files (common in recent games) can't be read, and fail with FFmpeg's error. docs/ENGINES.md says so.

Settings

v43 (CurrentSchemaVersion = 43): existing libraries learn .usm on the video donut with LearnExtensions, as .dst (v38) and .ps1 (v39) did, and custom claims stay put. Your #505 (FITS) may also need a settings step, so the two numbers may need sorting out depending on which merges first.

Tests

• UsmFormatTests (Core):
  • .USM is detected as a read-only video and picks the video donut.
  • A version 42 library learns usm once.
• MediaTests: usm → mp4 is one FFmpeg step, and nothing routes to USM.
• dotnet format --verify-no-changes is clean.
• Full dotnet test: Core 543, Platform 79, CLI 27, Setup 149, Engines 1711 and App 986 pass, none fail.

Not checked: a real .usm conversion. I don't have a sample file, and FFmpeg has no USM muxer to make one. If the reporter can share an unencrypted clip, an end-to-end test could be added.

[cre8ive-marketing]

Merged main. #505 (FITS) took settings schema 43, so the USM step is now v44 (CurrentSchemaVersion = 44), right after FITS, and its test upgrades a version 43 library. Core (549) and the media / FITS / route engine tests (222) pass. The earlier Linux CI failure was the new route test running where FFmpeg isn't installed; it now skips there like the other media tests (8fd7da9).