macOS: hold keystrokes back during a correction

[vstrelnikof]

Same feature as the Windows twin issue, macOS flavour. Today the key gate (hold your keystrokes while a correction types, replay them behind it) exists only on Linux/evdev; on macOS a keystroke can still land inside a correction and scramble it.

Mechanism: a CGEventTap callback can swallow an event by returning NULL, and our tap is already active. macOS-specific hazards:

• Tap timeouts. If the callback blocks, macOS disables the tap (kCGEventTapDisabledByTimeout) — the swallow decision must be instant, with held events queued to the worker thread, and the tap re-enabled defensively if the OS ever cuts it.
• Injected events are already stamped (0.6.2) so the gate can pass our own emissions through — the same self-deadlock guard the evdev gate needed.
• Replay must preserve ordering relative to the correction's own backspaces/retype, and accept that a mid-correction chord may be unreproducible (documented loss on Linux; same call here).
• Needs real-hardware validation — this cannot be trusted from CI (see the Apple Silicon validation issue for context on how little of macOS is exercised there).

Where to look: crates/poltertype-input/src/ — evdev KeyGate is the reference; macos.rs holds the tap. docs/PERMISSIONS.md states the user-facing contract per OS.

[vstrelnikof]

Still open, still wanted, deliberately not attempted blind — a gate that
swallows keystrokes system-wide is not something to write without a Mac to try
it on.

Two notes from PR #17 for whoever picks this up, both of which change the
starting position:

The tap now subscribes to FlagsChanged (#4), so the callback sees
modifier edges as well as key events. Anything held-and-replayed will have to
decide what to do with those: a modifier press swallowed during a correction
and replayed afterwards is a different proposition from a character, and
replaying it late can leave a modifier logically down.

The emitter now clears event flags on everything it posts (#5). That is
worth knowing because it means an injected event's flags no longer reflect the
hardware — a gate that tried to reconstruct "what was held" from our own
emissions would read zeroes.

The EMITTER_TAG stamping this issue relies on is unchanged and still the
right self-deadlock guard; to_key_event in
crates/poltertype-input/src/macos/listener.rs is where a swallow decision
would go, and it is already a translate-and-try_send with nothing blocking in
it.