fix(hotkey): never debounce a STOP, only a START

[mledour]

Finding #7 (code review): the debounce swallows a deliberate STOP

The 500 ms toggle debounce was direction-agnostic — it dropped any Ctrl+F9 edge landing within 500 ms of the previous toggle. But each edge toggles monitoring, so the swallowed second edge of a rapid pair is always the STOP. A user who deliberately tapped START then STOP within half a second had the STOP dropped → the writers kept running and the CSVs kept growing while they believed recording had stopped ("I stopped it and it kept recording").

(There's no way to distinguish a deliberate fast double-tap from a spurious OBS double-fire by timing — they're identical inputs — so honoring the deliberate STOP necessarily means the spurious case nets to OFF too. That's the better outcome anyway.)

Fix

Make the debounce direction-aware:

• STOP (target = OFF) → always honored.
• START (target = ON) → debounced (still stops a remapper/OBS/ShadowPlay firing Ctrl+F9 repeatedly from flapping the recording on).

Results:

• Deliberate fast START→STOP now ends OFF as intended.
• A spurious double-fire nets to OFF instead of leaving monitoring stuck ON — and its merge covers only the handful of frames in that <500 ms window (cheap; not the 10-50 ms stall of a full session that the original debounce comment worried about).

Verification

The hotkey path lives in xrEndFrame (needs a live layer + simulated key state), so — like MergeIntoOutput and the rest of it — it's covered by the build + review rather than a unit test. One file, layer.cpp (+33/−22); no lines >120 cols.

🤖 Generated with Claude Code