Menu hover steals DOM focus from in-menu text-entry controls (e.g. a search input) #748

Describe the bug

When a menu renders a text-entry control alongside its items (search-in-menu), every pointer hover moves DOM focus away from it. Menu.Item.onPointerMove and Menu.SubTrigger.onPointerMove call focusWithoutScrolling(row), row pointerleave refocuses the content via _focusContent(), and the focused-key sync effect in createSelectableItem re-focuses the row whenever setFocusedKey runs. The caret restarts its blink on every mouse move and typing is interrupted; consumers currently work around it with rAF refocus loops.

To Reproduce

1. Render a DropdownMenu whose content contains a text input alongside items; focus the input
2. Move the mouse across the items
3. Focus lands on the row / menu content instead of staying in the input

Expected behavior

With a text-entry control inside the menu focused, hover keeps DOM focus there, while selection-manager state (setFocused/setFocusedKey) still updates so data-highlighted and Enter-to-select keep working.

Screenshots

Before/after recordings available — the consumer PR linked below has them.

Desktop (please complete the following information):

• OS: Linux
• Browser: Chromium
• Version: @kobalte/core 0.13.14

Additional context

Proposed fix (a consumer patch already implements this and is verified end-to-end): skip only the focusWithoutScrolling calls at the four sites — item onPointerMove, sub-trigger onPointerMove, _focusContent(), and the createSelectableItem focused-key effect — gated on document.activeElement being an editable (input/textarea/contenteditable) inside the same [role="menu"]. Selection-manager updates stay unconditional. Measured in the consumer: focus operations during a scripted hover sweep went 140 → 0 with highlight/Enter intact, including a submenu that renders its own search field.

Design note: with focus pinned to the field, Enter selection must be forwarded by the consumer — createSelectableCollection has no Enter case and only createSelectableItem.onKeyDown handles Enter, which requires the row to hold DOM focus. A content-level Enter handler selecting focusedKey would let search-in-menu consumers work with zero glue.

Consumer context: found while fixing anomalyco/opencode#56868 (PR: anomalyco/opencode#56873). I have a source-level fix ready on a branch and would like to contribute it per CONTRIBUTING.