Closes #27 once verified on a Windows host.

Summary

Two bugs on Windows prevented the hotkey paste flow from working. This PR addresses both.

Bug 2 (confirmed deterministic fix)

Configuring the hotkey to ctrl+shift+v made paste silently fail:

• windowsSendCtrlShiftV synthesizes Ctrl+Shift+V via SendKeys.
• That synthesized keystroke is intercepted again by our own RegisterHotKey loop, and the hotkeyRunning re-entry guard swallows it.
• Plain ctrl+v would also hijack the system paste shortcut.

parseHotkey now rejects ctrl+v and ctrl+shift+v with explanatory error messages (regardless of casing or modifier order), and saveHotkeyConfig inherits the validation. The default alt+shift+v is unaffected.

Bug 1 (persistence hardening, needs Windows smoke verification)

Clipboard data vanished between windowsSetClipboardText and windowsSendCtrlShiftV:

• Set-Clipboard / Clipboard.SetText give clipboard ownership to an internal window inside the short-lived PowerShell process.
• When the process exits, Windows destroys the window and empties the clipboard.

The fix adopts explicit persistence semantics rather than asserting a single root cause:

1. Use Clipboard.SetDataObject(data, $true) — WinForms' documented "leave the data on the clipboard after this app exits" contract.
2. Call OleFlushClipboard() as a belt-and-braces commit, because the exact persistence path for delayed-render formats (notably Bitmap) depends on Windows version and format. Using both keeps the fix robust without relying on any single API.

The same treatment is applied to windowsSetClipboardImage (used for the optional --restore-clipboard flow).

Tests

Added table-driven tests in cmd/cc-clip/hotkey_windows_test.go:

• TestParseHotkeyAccepts — default, casing, extra modifiers, function keys
• TestParseHotkeyRejectsPasteConflicts — ctrl+v / ctrl+shift+v across casings and modifier orderings
• TestParseHotkeyNonVKeyNotRejected — scope check: the rule must only target the V key
• TestSaveHotkeyConfigRejectsPasteConflicts — end-to-end rejection at the config layer

Verification performed locally

• make test — full suite passes on darwin
• make vet — clean
• GOOS=windows GOARCH=amd64 go build ./cmd/cc-clip — passes
• GOOS=windows GOARCH=arm64 go build ./cmd/cc-clip — passes
• GOOS=windows GOARCH=386 go build ./cmd/cc-clip — passes
• GOOS=windows GOARCH=amd64 go vet ./cmd/cc-clip — clean
• GOOS=windows GOARCH=amd64 go test -c ./cmd/cc-clip — Windows-tagged tests compile cleanly

Verification still needed (Windows host)

I do not have a Windows host, so the runtime behavior of the clipboard persistence change must be confirmed by someone who does. Requested smoke checks:

• cc-clip send --paste on Windows 11 with Git Bash / Windows Terminal: image uploads and remote path is actually pasted into the terminal
• cc-clip hotkey --run-loop with default alt+shift+v: copy image → hotkey → path pasted
• Configure hotkey to ctrl+shift+v via the config path: rejected with a clear error message
• Configure hotkey to ctrl+v: rejected with a clear error message
• With --restore-clipboard, the original image is back on the clipboard after paste

@nucleoid — would you be willing to test this branch on your Windows 11 setup? Binaries can be built from this branch, or I can attach prebuilt .exe artifacts if you prefer.

Files touched

• cmd/cc-clip/hotkey_windows.go — conflict validation in parseHotkey
• cmd/cc-clip/hotkey_windows_test.go — new tests
• cmd/cc-clip/send_windows.go — SetDataObject(..., $true) + OleFlushClipboard wrapper, applied to both text and image setters

Refs #27.