[Bug] Selftest `UseIsCovered_RerendersOnZOrderChange` fails ~3 of 5 runs in isolation

Splitting this out of #988 rather than letting it be absorbed, because it shares that issue's outward signature (a single selftest fixture failing intermittently in an otherwise-green run) but **not its mechanism**.

## Discriminator against #988 and #978

| | #988 (budget kill) | #978 (silent mid-run death) | this |
|---|---|---|---|
| `# Total failures:` trailer | interrupted before it | never reached | **present** |
| downstream fixtures | all `Skipped` | missing | **all run normally** |
| victim identity | roams between runs | roams between runs | **always the same check** |
| suite duration | at/over the cap | well under | **well under** |

It is a genuine `not ok` on one named check, reproducible under `--filter`, with the rest of the suite unaffected. Neither the budget work in #1012 nor anything in #978 touches it.

## Location

`tests/Reactor.AppTests.Host/SelfTest/Fixtures/Phase7WindowingFixtures.cs`, class `UseSpec054HooksSuite` (registry name `UseSpec054Hooks_Suite`):

```csharp
win.RaiseZOrderChangedForTests(movedToTop: false, isCovered: true);
bool coveredUpdated = await Harness.WaitFor(
() => component.Covered && component.RenderCount > renders,
maxPasses: 10, perPassMs: 20);
H.Check("UseIsCovered_RerendersOnZOrderChange", coveredUpdated);
```

## Observed

**3 of 5 runs failed** when run in isolation via
`dotnet run --project tests/Reactor.AppTests.Host --no-build -c Debug -p:Platform=x64 -- --self-test --filter "UseSpec054Hooks_Suite"`.

Every other check in the same fixture passed in every run, including the four picker checks immediately after it, so the fixture reaches the end normally.

## What I have *not* established

Being explicit about this, because the failure mode of flake triage is a confident wrong cause:

- **I did not test whether raising `maxPasses` fixes it.** Per `AGENTS.md` § *Checks that actually prove something*, a budget increase would only refute the "sampled too early" class of race — an event that never fires, or an ordering race decided before the first poll, is budget-insensitive. So I am reporting the observation, not a diagnosis.
- **`WaitFor` is the correct tool here and is not vacuous.** The predicate is *convergent* — false at `t=0`, expected to become true — which is exactly the case `WaitFor` suits. This is not an instance of the survival-assertion trap.
- **The machine was non-interactive** (`GetCursorPos` → `ACCESS_DENIED`). `RaiseZOrderChangedForTests` is a synthetic raise, so this *should* be independent of real desktop Z-order, but I have not confirmed the hook doesn't also observe real window events. Worth ruling in or out on an interactive box before assuming it is environmental.

Note that 200 ms is a short budget for a path requiring both a hook state update *and* a subsequent re-render, so the poll window is a reasonable first place to look — but see the first bullet.

## Confidence sizing

At the observed p ≈ 0.6, three clean runs would occur only ~6 % of the time by chance, so a handful of greens would be reasonable corroboration of a fix here — unlike a low-rate flake. A *mechanism* that explains the failure is still worth more than any run count.

Found while validating #1012 (fix for #988), on a tree that does not touch this fixture.

Start in tests/Reactor.AppTests.Host/SelfTest/Fixtures/Phase7WindowingFixtures.cs at UseSpec054HooksSuite and run the filtered dotnet command from the report. Inspect RaiseZOrderChangedForTests, WaitFor, and the hook/render path, using AGENTS.md’s checks guidance. Done means the failure mechanism is established and repeated isolated runs reliably pass without weakening the assertion.

Written by the indexing model from the issue text.