Stand up the Tier-5 behavior-canary CI suite

## Problem / goal

Stand up the Tier-5 behavior-canary CI suite: a dedicated, non-blocking job that pins field-verified-but-undocumented Windows behaviors so a future OS servicing update that breaks one of Bastion's observed-behavior assumptions is caught automatically instead of surfacing as a confusing user bug report.

## References

- `DESIGN.md` §11 (Tier 5 description) — pins field-verified-but-undocumented behaviors per Windows build: `MoveWindowToDesktop` own-process success/foreign-process `E_ACCESSDENIED`, shell-cloaking of inactive-desktop windows, UIPI `ERROR_ACCESS_DENIED` on `SetWindowPos`/`ShowWindow` against elevated windows, `ERROR_HOTKEY_ALREADY_REGISTERED` conflicts, `SW_SHOWNOACTIVATE` restore-from-arranged semantics, cross-process `DWMWA_WINDOW_CORNER_PREFERENCE` acceptance, ApplicationFrameHost child structure.
- `docs/engineering/testing.md` §2 — Tier 5 tests are tagged `[Trait("Category","Canary")]`, run as a separate, non-blocking early-warning job that opens tracked issues on failure rather than gating merges.
- `docs/engineering/testing.md` §7 (CI runner realities) — `windows-latest` is Server 2025 build 26100, not the 25H2/26200 DESIGN.md actually targets — a green run there is a weaker proxy, not equivalent validation; true build-26200 coverage needs a self-hosted 25H2 runner or the Tier 4 Sandbox leg, both currently unprovisioned.
- `.github/workflows/ci.yml`'s own trailing comment block, which explains exactly why this job was deliberately deferred until a first canary test exists (Microsoft.Testing.Platform's zero-discovered-tests hard failure — see `docs/engineering/testing.md` §1/§2).

## Acceptance criteria

- [ ] At least the first canary test (e.g. the UIPI `ERROR_ACCESS_DENIED` behavior, since the v0.2 elevated-window-detection issue already depends on it) is written and tagged `[Trait("Category","Canary")]`.
- [ ] A `.github/workflows/ci.yml` job runs `dotnet test --filter-query "/[Category=Canary]"` on `windows-latest`, non-blocking (does not gate PR merge).
- [ ] A canary failure is wired to open (or comment on) a tracked GitHub issue automatically, or the job's output makes this trivial to do manually if full automation is out of scope for this issue (state which was achieved).
- [ ] The job description/README notes explicitly that `windows-latest` validates against Server 2025 build 26100, not DESIGN.md's stated Windows 11 25H2/build 26200 target, per `testing.md` §7.

Start with DESIGN.md §11, docs/engineering/testing.md §§1, 2, and 7, and the deferred-job comments in .github/workflows/ci.yml. Add the first Tier-5 canary for the stated UIPI behavior, tag it Category=Canary, and configure the non-blocking windows-latest job with its build-26100 limitation documented. Confirm the workflow runs the filter and that failure handling is either automated or clearly actionable.

Written by the indexing model from the issue text.