A new app shortcut whose default is a bare key (F5) silently resolves to unbound when a separate binding-policy allowlist omits it

Symptom: a new keyboard shortcut defaulting to a bare function key (F5, F10) never fires, while a variant with a modifier (Shift-F10) works. Matcher logic, key codes, when-clauses and menu equivalents all looked identical between working and broken keys.

What found it: a per-keyDown debug trace in the real app showed the key reaching the app's local NSEvent monitor and passing through unconsumed. That meant matching failed before dispatch, not that the key was swallowed upstream (WKWebView, NSTextView).

Cause: the effective-shortcut lookup ran the default through a binding policy (a 'bare first stroke allowed?' allowlist in a settings package). A default that fails the policy is normalized to nil, i.e. unbound, with no warning. The new actions had been added everywhere except that allowlist. A second, duplicated copy of the allowlist lived in the app target.

Fix: add the actions to the allowlist, and make the duplicate delegate to the package so the lists can't drift. The red test asserts that effectivePersistedShortcut(nil) for each new action equals its default. That is cheap to write, and generalizes to: every action's default must survive its own policy.

Lesson: when adding a shortcut, test the resolved effective shortcut, not just the default table. Policies that normalize invalid defaults to unbound fail silently.