Send F6 and F10 to a focused Windows terminal

[coneilen]

Summary

A focused Windows terminal now gets F6 and F10 instead of the shell consuming them. F6 (Focus Window Toolbar) and F10 (native menu bar) were taken by the shell even when a terminal had focus. Ctrl+S is deliberately NOT changed by this PR (see the known limitation below).

Changes

• TerminalKeys.routeChord: F6 and F10 (with or without Shift) are terminal input; new menu_bar route for Ctrl+Shift+F10 posts SC_KEYMENU so the menu bar stays reachable from a terminal.
• MainWindow.dispatchMessageWith: a terminal-owned key skips the shell's key hook and the buffered native-F10 pair, so a terminal F10 is not handed to default menu processing. Outside a terminal F6 and F10 behave as before; Shift+F10 stays the terminal context menu.
• InputRouter.headerKey: Ctrl+Shift+F6 enters/leaves the window toolbar from anywhere (first control, not last).
• View > Focus Window Toolbar and Help > Keyboard Shortcuts show the new chords.
• Tests cover the F10 key-down / focus change / key-up case, and that Ctrl+S, T, D, W and N still add no shell-encoded bytes (plain Ctrl+S stays 0x13).
• README key text and the parity ledger row updated; the ledger row stays Partial. Alt and Alt+letter were already terminal input before this PR, so menu mnemonics are unavailable while a terminal has focus; Ctrl+Shift+F10 or the mouse reaches the menu bar.

Known limitation (not fixed here): Ctrl+S

In a program that reads keys with line input on (for example pwsh [Console]::ReadKey), conhost's pause-output handling swallows Ctrl+S and the next key; Ctrl+T alone works. A win32-input-mode workaround was tried and rejected: an isolated zmx 785b3fd matrix showed it breaks Git MSYS vim (Enter no longer honored) and makes cmd.exe insert a literal ^S. That evidence is not a Dev Box walkthrough. This PR does not claim Ctrl+S works.

What is and is not proven

All tests stop at the in-process input queue or synthesized message dispatch (including the live key table, which sends synthesized WM_KEYDOWN into a real Winghostty surface). Nothing in this PR was run against a real conhost, pwsh, zmx, or a Dev Box, so these tests do NOT show that F6/F10 reach a program in a focused terminal end to end, or that the menu bar is never left active in a real session. The F10 menu-bar behavior is covered by a hidden real-window fixture (down, focus change, up), not a live walkthrough. The live fixture window is not eligible for the native F10 path, so it shows no F10 RED.

Test plan

Pinned Zig 0.15.2 and the pinned Winghostty provider from Tools\windows\bootstrap.ps1, with a scratch USERPROFILE, APPDATA, LOCALAPPDATA, TEMP and GRAPHCODE_SUPPORT_DIR.

RED: zig test src\MainWindow.zig -target x86_64-windows-msvc -lc -luser32 -lgdi32 -ladvapi32 -I...\winghostty\include -> F10 test "plain and Shift F10 reach a focused terminal" failed: expected 1, found 0; F6 test failed: expected 0, found 1; TerminalKeys routeChord test failed: expected .terminal, found .default; App live key table failed: key F6 expected ESC[17~ observed empty
GREEN: same focused commands after the change -> TerminalKeys 10/10, MainWindow F10 filter passed, TerminalSurface "every function key" 1/1, App "live terminal keyboard" 5/5 passed
REGRESSION: zig test of App (all 1011), TerminalSurface (233), MainWindow (71), TerminalKeyEncoding (39), TerminalKeys (10), InputRouter (9) via the repo's exact test invocations -> all passed

Checklist

• I have read the Contributing Guidelines
• I have signed off my commits (git commit -s) per the DCO
• Tests pass locally (make test) - macOS target; not applicable to this Windows-only change, Windows Zig tests listed above passed
• Code follows the existing style (make check) - macOS lint; not run
• I added the test/contract before the implementation and observed the intended RED failure