Close the biggest test gaps: composed resource keys, commands, tool discovery

[Kentarohakase]

Stacked on #3. Phase 3 of the improvement plan: 239 tests, up from 204.

The gap that could ship a bug to users

Several texts are looked up under a key composed from an enum value — ValidationFinding_{kind}_Title, AnalysisFinding_{kind}_Message, BatchStatus_{status}, and six more families. Adding a member to AudioComparisonFindingKind or BatchProcessingStatus produced no compiler error and no test failure; it simply shipped a missing-resource marker into the interface.

ResourceTests.VisibleModelTexts_DoNotContainMissingResourceMarkers walked a hand-maintained list of about sixty values, so it could not cover this. ComposedResourceKeys_ResolveForEveryEnumValue now enumerates every member of every enum used that way and resolves the keys it produces, in both languages.

I verified it actually bites rather than trivially passing: adding a member without a resource entry turned it red and named exactly the two missing keys.

Collection: ["ValidationFinding_TemporaryFalsificationProbe_Titl"..., "ValidationFinding_TemporaryFalsificationProbe_Mess"...]
Failed!  - Failed: 2, Passed: 0

The probe member was removed again.

New coverage

• CommandTests — AsyncRelayCommand, RelayCommand and RelayCommand<T> had no tests at all, although AsyncRelayCommand carries the guard that keeps a failing command from ending the session (Keep failing commands, slow tools and untrusted update links from breaking the session #2). Covered: reentry is blocked while a run is in flight, the error handler receives the failure, a cancellation is a normal outcome, the command becomes executable again afterwards, and the typed parameter handling including a mismatched type.
• ResultTests — including the case every consumer has to remember: a failure may still carry a value, which is how a critical validation report reaches the UI.
• ToolDiscoveryServiceTests — 245 lines that had no tests. Covered: path resolution, the fallback to the bare executable name, the caching of a successful probe, and the caching of a failed one from Make long running steps cancellable and keep the queue from stalling the UI #3. The probe uses where.exe /? — always present on Windows and the same shape as <tool> -version, without needing FFmpeg on the runner. (cmd.exe /? is unusable: it prints help but exits 1.)
• AppUpdateServiceTests — CheckAsync had no tests despite AppUpdateService having an internal constructor that takes an HttpClient specifically to make it testable. A FakeHttpMessageHandler covers a newer release, an up-to-date version, an untrusted link falling back to the releases page, a 404, a malformed payload, a missing tag, an unreachable host, and cancellation.

One production change

AppUpdateService.CheckAsync caught OperationCanceledException along with everything else, so a caller that cancelled was told there was no update. It now rethrows when the caller's own token was cancelled; its internal timeout still surfaces as "no update".

Latent flakiness removed

LocalizationService.Instance.Culture is process-wide state and its setter also writes CultureInfo.DefaultThreadCurrentUICulture. Six test methods across four classes mutate it while other classes assert on localized text, and xUnit runs test classes in parallel by default. The suite takes nine seconds, so serializing it via [assembly: CollectionBehavior(DisableTestParallelization = true)] is the cheap and complete fix.

Verification

dotnet format .\AudioQualityEnhancer.slnx --verify-no-changes   -> clean
dotnet build  .\AudioQualityEnhancer.slnx -c Release            -> 0 warnings, 0 errors
dotnet test   .\AudioQualityEnhancer.slnx -c Release            -> 239 passed, 0 failed

Still not covered

MainViewModel — about 2,100 lines across eleven partials — remains untested. Its constructor instantiates eighteen services itself and is the de-facto composition root, so there is no seam to construct it in a test. That needs a constructor refactor, which is its own change rather than a by-product of this one.