Accessibility story for docking windows — investigation needed

## Context

While fixing #419 (E2E test reliability for tab tear-off), we hit a class of failures that points at a deeper concern than just the tests:

- **Cross-window UIA interactions break mid-drag.** When the source floating window is hidden mid-tear-off (`BeginFloatingTearOff` → `AppWindow.Hide()` on the single-tab path), WinAppDriver's UIA-driven input pipeline freezes — subsequent moves never reach the host's overlay handlers. Detailed `Tracker.OnTick` / `Overlay.PointerEntered` tracing confirmed the cursor moves at the OS level but the host's WinUI input dispatch isn't seeing the events.
- **Dragged-preview window opacity bypasses WinUI's hit-test logic, not UIA's.** `WS_EX_TRANSPARENT` makes the OS `WindowFromPoint` skip the preview, but UIA's tree walkers still see the preview as a top-level window covering the cursor. The same mechanism that breaks tests would break a screen reader trying to announce or interact with the drop target underneath.

If UIA-driven automation (which is essentially what an assistive technology IS) can't drive a float → host dock-back, neither can a JAWS / NVDA / Narrator user. We have a tested-and-shipping feature (#418) whose primary input modality is **not accessible**.

## What this issue is for

Track the investigation — not the implementation. Specifically:

1. **Audit our existing UIA surface for the docking pipeline.** What does the UIA tree look like during an active drag? Are drop targets named/announced? Can a user identify available targets without seeing them?
2. **Research how other docking-window solutions tackle accessibility.** Concrete candidates:
- Visual Studio's docking (likely the gold-standard reference — it's where the §2.6 design came from)
- JetBrains Rider / IntelliJ tool windows
- VS Code's drag-drop panel
- AvalonDock (WPF, open source — should have visible AT story)
- Telerik / DevExpress / Syncfusion docking controls
- WinUI 3 NavigationView's pane-positioning APIs (closest first-party analog)
3. **Identify what an accessible alternative input modality looks like.** Likely candidates:
- Keyboard-driven move/dock (already partially present — `keyboardOverlayActive` references in `DockHostNativeComponent.cs`). Is the existing keyboard-overlay flow discoverable / announced?
- A context-menu action for \"Move to floating window\" / \"Dock to ...\".
- An ARIA-equivalent live-region announcement strategy during drag.
4. **Decide what we owe the user before we promote this feature beyond Phase 0.**

## Out of scope (for now)

- Implementation. This is an investigation issue. Once we have a recommended approach, we'll spin off the implementation work as separate tickets.
- The #419 E2E tests themselves — those landed via #426 with the WinAppDriver-tractable scenarios green; the cross-window paths the AT story would need are covered today only by synthetic-event selftest fixtures.

## Related

- #418 — tab tear-off pipeline (the feature)
- #419 — E2E test reliability investigation (where this gap surfaced)
- #426 — PR that landed the 4/4 reliable E2E suite + documented the cross-window UIA limitation

## Acceptance criteria

A markdown doc in `docs/specs/045/accessibility-investigation.md` (or similar) that:
- Surveys the 3-5 most relevant docking implementations + their AT approaches.
- Recommends an accessibility story for our docking surface (or escalates if there's no clean answer).
- Lists the follow-up tickets needed to implement it.

Start with DockHostNativeComponent.cs and inspect the existing keyboard-overlay flow, then audit the UIA surface during an active docking drag. Compare the named docking implementations and their assistive-technology approaches. Done means a markdown report at docs/specs/045/accessibility-investigation.md or similar that recommends an accessibility approach and lists follow-up tickets.

Written by the indexing model from the issue text.