fix(terminal): allow Windows paste shortcuts

[Glucksberg]

Problem

Buzz Term encoded both Ctrl+V and Ctrl+Shift+V as the ^V control byte on Windows, then called preventDefault(). That prevented WebView2 from delivering the clipboard payload to the terminal's existing paste handler.

Implementation

• Detect paste chords before terminal key encoding.
• Let WebView handle Ctrl+V and Ctrl+Shift+V on Windows.
• Preserve the existing platform conventions: Cmd+V on macOS and Ctrl+Shift+V on Linux, while Linux Ctrl+V remains Readline quoted-insert.
• Match the logical event.key so alternate keyboard layouts work, and reject Alt/mixed-modifier chords.
• Keep clipboard text on the existing synchronous onPaste path, including bracketed-paste wrapping.

This is a focused follow-up discovered while field-testing #5425 / #4930. It is not a duplicate: #5425 fixes native PTY spawn, teardown, and PATH behavior; this PR fixes frontend keyboard event routing. I searched open PRs and issues for the Windows paste shortcuts and found no existing report or patch.

Tests

• Added platform-matrix unit tests for Windows, Linux, and macOS paste chords.
• Added a mounted Windows regression proving both shortcuts are not prevented, never send ^V, and paste exactly once through bracketed paste.
• Added a mounted headless Linux regression proving Ctrl+V still sends ^V, while Ctrl+Shift+V waits for the paste event and forwards the clipboard exactly once through bracketed paste.
• Targeted terminal suite: 35 passed, 0 failed.
• Full just ci component set passed. The aggregate invocation was interrupted during Tauri compilation only because the isolated worktree filled the host disk; after removing its regenerable root target/, just desktop-tauri-test and just mobile-test both passed. Notable totals: 2,383 Tauri app tests passed (14 environment-dependent tests ignored), terminal crate suites passed, and 1,261 Flutter tests passed.
• pnpm check, desktop typecheck, Rust fmt/clippy/check, web check/build, and git diff --check passed. The frontend check reports one warning and two informational findings already present on current main, outside these files.

Windows field proof

The exact patch was built and tested on Windows 11 before being cleanly rebased onto current main (the canary commit and the production-code commit in this PR have the same stable patch ID).

• Successful Windows canary workflow
• Canary commit: b00790a6ceb4cb0967fe07711d7174338cd92f8d
• Installer: Buzz_0.5.9-fork.8_x64-setup.exe
• Installer SHA-256: 049a0507694002af0f7232c3158f5915f0536fd9e260f506075404023695f4ef
• Manual result: both Ctrl+V and Ctrl+Shift+V paste once without emitting ^V. In shells with bracketed paste enabled, the temporary active-region emphasis clears on the next keypress as expected.

Manual test

1. Copy text in Windows and focus Buzz Term.
2. Press Ctrl+V; confirm it appears once and no ^V is inserted.
3. Repeat with Ctrl+Shift+V.
4. With shell bracketed paste enabled, confirm the temporary active-region styling clears on the next keypress.

Visual evidence

No screenshot is included because this changes keyboard event routing and has no persistent visual state. The Windows canary run and manual interaction results above are the relevant behavioral evidence.

Deferred work

None for this fix.