macOS: decide the fate of the modifier-keycode arms — the tap mask never delivers FlagsChanged

[vstrelnikof]

Follow-up from #1 (review discussion).

The macOS listener's event tap subscribes to KeyDown + KeyUp only. macOS delivers modifier presses as FlagsChanged (event type 12) — so the keycode→modifier match arms added for Apple modifier keys are currently unreachable: no event carrying those keycodes ever enters the callback.

Modifier state is still correct today because it's folded from the event flags on ordinary key events (including CGEventFlagAlphaShift → shift), so this is not a user-visible bug — it's dead code plus an open design question:

Option A — subscribe to FlagsChanged and route it through the modifier arms. That would give the engine discrete modifier press/release events like the X11 and Windows backends get. Things to check: tap-callback cost (the handler must stay non-blocking), whether the word-boundary logic actually wants those events, and that injected-event stamping still filters our own emissions.

Option B — delete the unreachable arms and keep flags-folding as the single source of modifier truth on macOS, with a comment explaining why.

Where to look: crates/poltertype-input/src/macos.rs (tap creation + keycode table). A decision + small PR either way closes this.

[vstrelnikof]

Option A — subscribed to FlagsChanged. PR #17.

Folding modifier state off ordinary key events is accurate the instant a
character key arrives and stale at every other moment: let go of Ctrl and
nothing tells us until the next keystroke. held_modifiers is read at the
start of a correction — often triggered by a chord, i.e. precisely when no
ordinary key is flowing — so the stale window is the window that matters.
That is also what #5 needed to fire at the right moment.

The arms are now live, which made one thing in this issue's framing wrong in
a way worth recording: kVK_Function (0x3F) rides the same FlagsChanged
stream and has no SC Set-1 equivalent, so the identity fallback would have
put it at SC-1 0x3F — inside the classifier's 0x3B..=0x53 "navigation, end
the word and discard it" range. Holding Fn to reach an arrow key would have
silently eaten the word in progress. Untracked modifier keycodes are dropped
in the listener instead.

The keycode table and the direction rules moved into macos/codes.rs, which
carries no Apple dependency and therefore compiles — and runs its tests — on
Linux and Windows CI. That was the other half of the problem: this project
has no Mac, and a wrong scancode there fails silently.

Rationale in docs/DECISIONS.md (2026-07-31).