test: point the integration suite's colour expectations at StatusColors

[laurentiu021]

Closes the first half of #2101 — and corrects its count.

Eleven assertions, not nine, across four files

StatusColors members are theme brush KEYS now (Good = "Success", Neutral = "TextMuted"), and every producer of a *ColorHex property assigns one. Eleven assertions in SysManager.IntegrationTests still compared against the pre-migration hex literals, so all eleven were permanently failing — and CI only dotnet builds that project, so nothing said so.

#2101 found nine in two files. Two more turned up while fixing them, in files the issue never named:

File	Assertions	Shape
HealthAnalyzerExtendedTests.cs	8	one Assert.Equal plus 7 [InlineData] rows
HealthDiagnosticTests.cs	1	Assert.Equal("#9AA0A6", d.ColorHex)
SystemHealthViewModelExtendedTests.cs	1	Assert.Matches("^#[0-9A-Fa-f]{6}$", …)
DiskHealthServiceTests.cs	1	same regex, on VerdictColorHex

The two Assert.Matches are why the issue missed them: it searched for hex literals, and a regex asserting hex shape contains no colour to grep for. The runner found them, not me.

Repointed at the member, not its value

Each expectation now names the StatusColors member the producer actually assigns — read off HealthAnalyzer rather than inferred:

Verdict	Member
Good	Good
LocalNetwork, Mixed	Bad
IspOrUpstream	Warning
GameServer, StreamingService	Info
Unknown	Neutral

Worth noting what the old rows recorded: GameServer was #F72585 and StreamingService #B388FF, two distinct colours that now both resolve to Info. The migration collapsed them, and these tests would have said so had they been able to run.

The two shape assertions get Assert.Contains(value, StatusColors.AllBrushKeys) — a stronger claim than the old regex, since it names the permitted set rather than a character class.

One production line

StatusColors.AllBrushKeys — the five distinct keys (Elevated shares Warning's). A copy of that list in the test would put a second source of truth inside the one class whose stated purpose is being the first. It adds no behaviour.

Also: the nav-order test asserted the wrong tab

NavItems_CorrectOrder_AboutLast asserted NavItems.Last().Id == "nav-about". Appending the Advanced group after Info made the real last entry nav-env-variables, and the test had been red ever since.

Rewritten rather than deleted, to the invariant that survived the change: NavItems_AboutIsLastInTheInfoGroup. Asserting About's position within its group cannot rot when a group is appended — only when About itself moves, which is the thing worth catching.

Verification

Ten of the eleven are pure computation and were run through a throwaway runner pointed at the integration assembly (kept outside the repo, so there is nothing to exclude from git). Reverting every expectation to its pre-migration literal — the state that shipped — gives:

3 green, 10 red
RED  AllVerdicts_ProduceValidColor[0..6]: Expected "#06D6A0" … Actual "Success" (and the other six)
RED  Good_HeadlineMentionsHealthy:        Expected "#06D6A0" … Actual "Success"
RED  Defaults_AreSafe:                    Expected "#9AA0A6" … Actual "TextMuted"
RED  Defaults_AreSafe:                    Regex "^#[0-9A-Fa-f]{6}$" … Value "TextMuted"

13 green, 0 red after restore, with all three files hashed identical.

The eleventh is not run here: DiskHealthServiceTests.EachReport_HasFriendlyNameAndMedia calls CollectAsync() and needs live WMI. Its assertion is the same shape as the Defaults_AreSafe one above, which is run and shows the exact failure.

Not addressed here: #2101's second point, that a project whose assertions cannot run anywhere in the pipeline will rot again. That is a CI question — a scheduled non-blocking job, or moving the pure assertions into the blocking suite — and it stays open on the issue.

Builds 0 errors / 0 warnings on all four projects, dotnet format --verify-no-changes clean on all four, 190 cases green in ArchitectureTests and the theme-contrast suites. test: — no version bump, no CHANGELOG, no release.