feat(win10-taskbar): take over the taskbar app-button context menu (Shell-styled custom menu)

[v4806]

Problem

On Windows 10, right-clicking a taskbar app button still pops the ShellExperienceHost XAML jump
list, even though the taskbar background menu is already owned by Shell.

Root cause

The button menu is not a Win32 menu: no #32768 window, no TrackPopupMenu(Ex), no
IContextMenu - no ordinary hook can see it. The only entry point is to subclass the taskbar button
area window and intercept WM_CONTEXTMENU.

Approach

• Subclass Shell_TrayWnd -> ReBarWindow32 -> MSTaskSwWClass -> MSTaskListWClass and intercept
  WM_CONTEXTMENU, swallowing it only when the click really lands on an app button; clicks in the gaps
  are passed through so explorer (and Shell) still shows the regular taskbar menu.
• Identify the button with UIA ElementFromPoint. ControlType must accept Button, MenuItem and
  SplitButton - a merged multi-window button is exposed as MenuItem. Button identity comes from the
  shell:AppsFolder\<AUMID> display name.
• Hand a custom HMENU to TrackPopupMenuExProc: Shell snapshots and re-themes it, so the menu
  looks native without any custom drawing.
• Items: app name (clickable - activates the window, or launches the app when it is not running) /
  pin / unpin / close window. Closing uses the UIA WindowPattern::Close() and closes every window of
  a merged button (one "Close all windows" entry); parallel fallbacks are used to bring elevated
  windows to the front.
• Pin / unpin: taskbarunpin verb on the pinned .lnk -> exe verb -> the official
  IStartMenuPinnedList fallback. After a successful pin the shortcut's AppUserModel property set is
  completed so it merges with the running window.
• The button menu gets its own context type FSO_TASKBAR_BUTTON: window.is_taskbar_button is true
  only there and window.is_taskbar returns false, so existing type='taskbar' rules (e.g. "Go to")
  do not leak in while .nss items can target the button menu directly.
• New built-in command.kill_process_tree terminates the process tree of all windows behind the button
  (leaves-first from a Toolhelp snapshot). window.taskbar_button_windows exposes the matched window
  count so configs can hide dead items on buttons whose app is not running.
• The hook covers the main taskbar and every secondary taskbar, and a background watchdog re-arms it
  every 3 seconds, so a rebuilt taskbar window (DPI change, monitor hotplug, theme switch) does not
  silently drop back to the native menu.

Scope

Windows 10 only - the hook is installed only when IsWindows11OrGreater() is false, so the
Windows 11 path is untouched. The changes are concentrated in Main.cpp; ContextMenu.cpp only adds
2 entry conditions.

Verification

Win10 22H2 + Shell 1.9.19:

Item	Result
Button menu	Shell-drawn style, no more XAML jump list
Pin / unpin	verified for running and not-running pinned items
Close window	UWP Settings, Edge, QQ, FlClash, Everything
Merged multi-window button	taken over as well; "Close all windows" closes every window
.nss customisation	where=window.is_taskbar_button items show up only in the button menu
command.kill_process_tree	[KILL] roots=2 processes=4 killed=4 (child processes included)
App-name item	brings the window to the front, elevated ones included (ok=1 fg=0x450166); launches the app when it is not running
Taskbar background menu	behaviour unchanged
Build	VS2026 + PlatformToolset=v145, release x64