The PR description claims "Match against quickSwitcherLabel first, then string label, then string value" but quickSwitcherLabel is never checked here. The actual behavior — matching label then value — is correct for dropdown type-to-select (since quickSwitcherLabel is a quick-switcher concern, not a dropdown concern), but the description should be updated to match reality.

This second useEffect is redundant. The effect at lines 241–258 already calls clearTypeahead() in its cleanup — both when its dependencies change and on unmount. This effect does nothing that isn't already covered.

Every other keyboard handler in MenuContent uses keybindings.registerKeybinding(), but the typeahead adds a raw window.addEventListener('keydown'). This works today because no registered keybindings match single-character keys, but it's an inconsistency that could bite if someone later registers a character-key binding. Consider using keybindings.registerKeybinding with a small wrapper, or at minimum add event.preventDefault() when a typeahead match is found to prevent downstream handlers from also reacting.

The onKeyDown wrapper adds no value over passing onTypeahead directly:

window.addEventListener('keydown', onTypeahead);
return () => {
  window.removeEventListener('keydown', onTypeahead);
  clearTypeahead();
};

The test name says "matches visible label when quickSwitcherLabel differs" but the assertion proves that quickSwitcherLabel is not matched — searching 'custom' (which matches quickSwitcherLabel: 'Custom Label') returns null. The test name should reflect what it actually verifies: that typeahead matches label, not quickSwitcherLabel.