Hardware debounce fix + Windows CI

Two separate but both overdue pieces of work landed in this session: a fix for an infuriating double-tap inversion bug, and the first working Windows build pipeline.

The double-tap inversion bug

Users reported that intentional double-taps were sometimes firing the single-tap action instead, and single taps were occasionally triggering double-tap actions. After adding some diagnostic logging, the root cause became clear.

The TAP Strap hardware emits spurious duplicate BLE notifications within roughly 10–30 ms of a genuine tap event. This is normal for the hardware (it's a byproduct of how the firmware debounces the capacitive sensors internally), but it was invisible to MapXr's engine.

With a double-tap binding present, the sequence looked like this to the engine:

1. Genuine tap event → engine starts waiting for a possible second tap
2. Hardware bounce (8 ms later) → engine sees a "second tap", advances to TapPending::Two, fires double-tap action
3. User's actual intended second tap (150 ms later) → engine has already resolved, starts a new single-tap sequence

The fix is a 50 ms debounce window per device: if the same tap code arrives from the same device within 50 ms of the previous event, it's silently discarded. Real double-taps arrive 100–300 ms apart, well outside the window. Dual-device profiles (where two TAP Straps legitimately stack same-device events for cross-device combo detection) are exempt from debouncing.

Windows CI via GitHub Actions

The workflow uses tauri-apps/tauri-action@v0 on a windows-latest runner. It produces both an .msi installer and an NSIS .exe as build artifacts, uploaded to the GitHub Actions run. The workflow triggers on workflow_dispatch or a v* tag push, so it doesn't burn CI minutes on every commit.

GITHUB_TOKEN is a GitHub built-in secret, so no manual secret creation is needed. The repo just needs "Read and write permissions" enabled under Settings → Actions → General for the release upload step to work.