Live UIA gate: replace fixed sleeps before assertions with bounded polling

[coneilen]

Summary

The live UIA gate contains 106 fixed Start-Sleep -Milliseconds calls, of which 50 are immediately followed (within 3 lines) by a Require assertion. Each of those is a sleep-and-hope race: if the shell has not reached the expected state within the hard-coded delay, the assertion fails even though the product is correct.

This has been producing flakes that are repeatedly, and reasonably, misattributed to whichever PR happened to be running.

Why this is worth fixing now

Recent examples observed across parity sessions, all in shared code well downstream of the PR under test:

• Quick Chat invocation did not perform its expected action - Start-Sleep -Milliseconds 150 then an immediate status-text assertion.
• sidebar rows were unavailable before dynamic invocation.

Both were hit by a canvas PR that touches neither area, and each run failed at a different point - the signature of timing, not a regression.

The cost is not just a re-run. Every one of these burns reviewer time proving a negative, and it trains everyone to dismiss gate failures as "probably flaky" - which is exactly how a real bug gets waved through. We already had one case where a genuine product bug (#437) was initially written off as environmental foreground contention.

The fix

The gate already has the right primitives:

• Wait-ForDesktopElement
• Wait-ForDesktopElementGone
• Wait-ForPopupMenu

All poll with a bounded deadline and emit focus diagnostics on timeout. The work is to convert sleep-then-assert sites to wait-for-condition, most of which need a small Wait-ForCondition-style helper for "poll until this scriptblock is true, then assert."

Worth prioritising the ~50 race-prone sites over the remaining 56 (settle delays not directly gating an assertion, which are lower risk).

Acceptance

• A new bounded polling helper for arbitrary conditions, with diagnostics on timeout.
• The 50 sleep-then-assert sites converted.
• No assertion depends on a fixed delay having been long enough.

Related

• Re-enable modal owners before destroying the modal #437 - fixed a genuine product bug (modal teardown re-enabled its owner after destroying the dialog) that had been presenting as gate flakiness. The gate assertion there was correct; the product was wrong. Distinguishing the two classes quickly is the point of this issue.