useHotkeys: ignore keys that belong to an IME composition

[mahirhir]

Summary

handleWindowKeyDown in useSingletonHotkeys now returns early when e.isComposing is true or e.keyCode === 229, so keys an IME is handling never reach registered hotkeys. With a Japanese, Chinese or Korean IME, the Enter that confirms a conversion no longer makes Autocomplete select the highlighted option or call onEnter. Escape and arrow keys pressed during a composition are skipped the same way.

The keyCode check is for Safari, which fires compositionend before the keydown of the confirming Enter, so isComposing is already false on that event.

Related Issue

Fixes #671

Screenshots / Recordings

None, there is no visual change.

Notes for Reviewers

• The issue also suggests e.key === "Process". I left it out because the check MDN recommends (isComposing || keyCode === 229) already catches the first and last keydown of a composition, where isComposing is false. Happy to add it if you prefer.
• The guard sits in the shared window handler, so it applies to every useHotkeys consumer, not only Autocomplete. Skipped keys are also not added to the pressed-key map.
• New story useHotkeys > ignores IME composition dispatches a composing Enter and a Safari-style Enter (keyCode: 229, isComposing: false) on window, then a normal Enter. On main it fails (the hotkey is called twice for the IME keydowns); with the change it passes.
• Locally: vitest --project=storybook 594 tests passed, --project=unit 181 passed, oxlint, oxfmt and tsc clean. I have not tried it with a real IME in a browser.
• Added a patch changeset.

[blvdmitry]

Looks good, thanks for the contribution 🙌