Replace the taskbar observer UI Automation subscription with Win32 shell signals

[rimtty]

Summary

• What changed: QuickPods.TaskbarObserver.exe no longer registers a UI Automation event subscription. It drives invalidation from a hidden shell hook window (RegisterShellHookWindow), a SetWinEventHook registration scoped to the Explorer process and the taskbar HWND tree, registry change notifications for the taskbar settings keys, shell broadcast messages, the existing 250 ms Explorer identity poll, and a 400 ms settle timer. Title redraw notifications are ignored while taskbar labels are hidden (the default) and throttled to once per second otherwise. The observer drops UseWPF; the wire contract (v7), host lifecycle handling, job-object containment, and the host's one-shot UI Automation scans are unchanged. The classification logic lives in a pure TaskbarSignalPolicy with unit tests.
• Why it changed: UI Automation event subscriptions are wired desktop-wide by the UI Automation core, so Chrome treated the observer as an assistive-technology client, enabled its accessibility mode, listed quickpods.taskbarobserver.exe under chrome://accessibility, and burned CPU. Raw diagnostics on a live machine also showed some applications emit HSHELL_REDRAW several times per second, which motivated gating redraws on the label setting.
• User or maintainer impact: Browsers no longer detect QuickPods as an accessibility client (restart the browser once after updating). Steady-state observer signal rate is zero; opening or closing windows, pin changes, alignment or auto-hide changes, display or theme changes still trigger re-discovery within about one second, and the 5-second host watchdog remains the last resort. ADR-0002 documents the decision and supersedes the rationale of ADR-0001 while keeping the process boundary.

Related issue

Closes #

Validation

• ./build/Test-RepositoryPublicReadiness.ps1
• dotnet format QuickPods.sln --verify-no-changes --no-restore --severity warn
• dotnet build QuickPods.sln -c Release --no-restore
• dotnet test QuickPods.sln -c Release --no-build --no-restore -- RunConfiguration.TreatNoTestsAsError=true (Foundation: 189 passed, including 40 new TaskbarSignalPolicyTests)
• Hardware, DPI, Explorer, startup, or installer validation is attached when applicable

Local validation on Windows 11:

• The new observer process loads no UIAutomation* or Presentation* modules (the previous build loaded ten), stays alive across a 30-second idle run with no ObserverFaulted log entries, and keeps a stable handle count.
• A reflection probe hosting TaskbarSignalSubscription reported zero signals at steady state and delivered window-created signals plus one settle signal when a console window opened; raw diagnostics confirmed HSHELL_WINDOWCREATED and HSHELL_WINDOWDESTROYED both arrive.
• Not run here: the chrome://accessibility check after a browser restart and build/Test-ExplorerRecovery.ps1 -ConfirmExplorerRestart; both are listed in ADR-0002 Verification.

Documentation and privacy

• User-visible and maintainer-facing documentation is updated (ADR-0002, ADR-0001 note, architecture README, docs index, development, troubleshooting, CHANGELOG)
• Logs and screenshots were reviewed for credentials, account data, and raw device identifiers
• No generated artifacts, dumps, certificates, keys, or machine-specific files are included

Remaining risk

• Known limitations: Windows 11 taskbar buttons are XAML elements without HWNDs, so button-level changes are inferred from shell hook, registry, and settle signals rather than observed directly. Registry key names may change across Windows releases; every watch is optional and degrades silently.
• Follow-up work: Consider SHAppBarMessage position notifications if a placement change ever goes unnoticed within the watchdog interval.