fix: make the status colours follow the theme instead of staying dark-calibrated

[laurentiu021]

Closes #1629.

The problem

StatusColors held six const string hex literals. A const is baked in at compile time, so ThemeService could never recompute them — and every *ColorHex property that feeds HexToBrushConverter carried them: System Health verdicts, disk health and wear percentages, drive temperatures, the Dashboard health score, Cleanup's SFC/DISM results, and the network-health headline.

I re-derived the contrast against the worst-case light card (soft-blossom Surface2 #FBCFE8) rather than trusting the reported figures — it's worse than the issue estimated. All six fail AA:

	old value	on a light card
Good	#22C55E	1.65:1	✗
Warning	#F59E0B	1.55:1	✗
Info	#3B82F6	2.66:1	✗
Elevated	#F87171	2.00:1	✗
Bad	#EF4444	2.72:1	✗
Neutral	#9AA0A6	1.91:1	✗

The fix

ThemeService already recomputes the equivalent semantic brushes per mode (StatusPalette: Success/Warning/Info/Danger), and ThemeStatusBrushTests already guards them. This string-hex path was simply never migrated — it was the one route that bypassed the fix.

So StatusColors now names that brush instead of duplicating a colour, and HexToBrushConverter resolves a key against the live theme resources using the same lookup OutputKindToBrushConverter already uses. Property names are unchanged, so not one of the 23 XAML binding paths moved.

After: 4.68–5.47:1 on the tinted light card, 5.27–9.25:1 on dark.

Two mappings worth calling out, both verified rather than assumed:

• Neutral → TextMuted, which Apply writes from the preset (12 distinct values across presets), not from StatusPalette. So it is theme-aware, just via a different route.
• Elevated → Warning. There is no separate "elevated" brush, and amber is the honest reading of "worse than fine, not yet failing". The old light red was both illegible on a light card and easy to mistake for the failure colour. A test pins the aliasing so it stays a decision, not an accident.

The cache trap

The issue flagged this and it was real: the converter's static cache holds frozen brushes, so caching a theme brush would keep serving the colour resolved at first render — status text would stay dark-themed after switching preset. Only literal hex is cached now; a resource lookup is a dictionary hit anyway.

Literal hex still resolves, which is why PingTarget's user-assignable per-series chart colours are untouched.

Propagate sweep found a second offender

HealthAnalyzer assigned eight raw hex literals directly, bypassing StatusColors entirely — and with a drifted palette (#06D6A0 not #22C55E, #FF6B6B not #EF4444), exactly the divergence centralising was meant to prevent. Routed through the same semantic keys. Grepped the codebase afterwards: no ColorHex = "#... remains anywhere.

Tests

50 assertions across 10 files asserted the literal hex. They now assert the semantic constant, so the palette can move without touching tests. ThemeStatusBrushTests gains the AA / legibility / mode-divergence contract for the new keys, plus a guard that fails if anyone reintroduces a # literal.

Two of my own new assertions failed on first run — and the tests were wrong, not the code:

1. TextMuted is not in StatusPalette (set separately by Apply).
2. Good-vs-Bad cannot be checked with WCAG contrast: that formula measures luminance, and light Success #166534 vs Danger #B91C1C are equally dark (1.10:1) while being obviously different hues. It compares RGB distance instead.

Recording that because a green suite on the first try would have meant those assertions weren't testing anything.

Verification

• 26/26 on the contrast + contract harness (the old-vs-new table above is its output).
• 8/8 on a harness driving the real producers — SFC verdict parsing, HealthAnalyzer verdicts — asserting the semantic mapping is right and no emitted value carries a #.
• All four projects rebuild --no-incremental: 0 errors, 0 warnings.

Not verifiable on this workstation: the on-screen result needs the app running, which is the secondary workstation's job. The contrast maths and the resolution contract are covered above.

Not in this PR

The rest of the theming cluster (#1625 chart series tints, #1623 MetricBlue/MetricPurple, #1624 sidebar hover, #1628 FilterChip, #1622 forced-dark title bar) is visual and wants before/after screenshots per preset — tracked separately. Note also the near-miss precedent there: an earlier sweep flagged 9 "dead" App.xaml brushes that were live via runtime TryFindResource; deleting them would have broken console colouring.