fix(gui): give both modules one background, and make the window paint it

[donislawdev]

The two halves of one app sat on two different backgrounds, and nobody had chosen either. The substitution panel and the window chrome were on the wpfui default, the calculator on our own palette base, with the seam visible under the module switch.

Why it happened

Background on a ui:FluentWindow is accepted by the parser, reads exactly like a working declaration, and paints nothing. Both windows carried one for their whole life. The calculator only looked right because it has its own root Grid background, which a Grid does honour.

Measured rather than reasoned - four probes, each rebuilt and screenshotted:

Probe	Result
Background="#FF00FF00" on MainWindow	0 px difference, screenshots identical byte for byte
override ApplicationBackgroundBrush and ApplicationBackgroundColor	0 px difference
override WindowBackground (the key its own style setter reads)	0 px difference
Background on the root <Grid> inside	works

The FluentWindow template pulled out of the package draws a ui:ClientAreaBorder with a correct Background="{TemplateBinding Panel.Background}", and none of the first three routes reaches it anyway. What ClientAreaBorder actually paints with is not established and not guessed at here.

A sweep giving each of the 14 Background declarations in the views its own bright colour found exactly two dead ones, both on FluentWindow roots. The other five that did not show up are Border elements in hidden states, and Border honours Background four times over in the same table.

What changed

The dead attribute is gone from both windows and the colour moved onto each content root. The base stays ours: the colour it replaced was a default of the dependency, so a wpfui release could have changed 86 percent of this window without anyone deciding it. It is also the first rung of a four-surface ladder tuned together - a card separates from it at 1.14 contrast where the other colour gives 1.08. Text contrast was never in question, 15.36 against 14.57 for primary text, both far above the floor.

Measured after, by pixel, on all three surfaces:

Surface	old colour	palette base
substitution panel	86.29% → 0	0.01% → 86.31%
calculator	12.80% → 0	12.39% → 25.19%
dialog	63.68% → 0	0.13% → 63.81%

The dialog carried the same dead attribute and nobody had counted it - 63.68 percent of its surface was the wrong colour. Stock wpfui controls re-tuned themselves without help, being roughly 6 percent white over whatever sits beneath them.

Guards

Two of them, because the obvious one is exactly the guard that would have missed this: a check on the attribute being present stays green on a declaration that paints nothing.

• Render guard - lays out MainWindow, renders its content and asserts the colour covering most of the surface, with a canary on the number of distinct colours so a blank render cannot pass for the wrong reason.
• Scan guard - parses each view as XML and refuses a Background on a FluentWindow root, with its own canary on how many views it walks and how many windows it finds.

Both seen red, on full runs: moving the declaration back onto the window reddens both, removing it altogether reddens only the render one. That second probe is what makes the pair worth having rather than one guard written twice.

Gates

12/12 · Rust 435 unchanged · C# 386 → 392 · harness 146 PASS / 0 FAIL

🤖 Generated with Claude Code