Give the audio quality rules a single home

[Kentarohakase]

Stacked on #5. The last open item from the improvement plan.

The problem

The numbers that decide when audio counts as weak were written out four times:

Location	What it decided
AudioAnalysisInsightService.cs:22-84	The analysis score and its findings
AudioProfileAdvisorService.cs:22-30	Which preset is suggested
AudioValidationService.cs:315-323	The findings on the exported file
MainViewModel.Insights.cs:55-88	The warning strip in the window

Each copy carried the same bitrate bounds (96 000 mono / 128 000 otherwise), the same sample-rate bound (32 000), the same headroom limit (−1.0 dB) and the same loudness band (−28 / −9 LUFS). Changing one of them would have made the application contradict itself — the warning strip saying one thing and the analysis report another — with no test to catch it, because each site was tested against its own copy of the number.

They happened to agree today. That is the point at which to merge them, not after they have drifted.

The change

Services/AudioQualityThresholds.cs holds the constants and the checks built on them. The four call sites ask that type instead of repeating the comparison, and AudioProfileAdvisorService.HasLowBitrate is gone since it was that check verbatim.

Two invariants the copies already agreed on are now stated once instead of being re-derived at each site:

• Low headroom excludes actual clipping. Clipping is reported on its own, so counting it as low headroom too would put the same problem in the findings twice. Every copy had the else if for this; now the predicate carries it.
• The two loudness bands cannot overlap, since −28 < −9.

Net: 24 lines added, 45 removed across the four call sites.

Why this is behaviour preserving

The rules are unchanged, and the existing suite already covers them from every side — AudioAnalysisInsightServiceTests (12 scoring cases), AudioProfileAdvisorServiceTests (7 advice cases) and AudioValidationServiceTests (18 report cases). All of them pass untouched.

The 26 new tests in AudioQualityThresholdsTests pin the boundaries themselves — 95 999 vs 96 000, 31 999 vs 32 000, −1.1 vs −1.0 — so a later change to one of those numbers has to be deliberate rather than accidental.

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            -> 265 passed, 0 failed

No changelog entry

Nothing changes for a user of the application: the same audio produces the same findings, the same advice and the same warnings as before.