Fix shadow DOM mouseleave detection in editor

[nick-romano]

Bug:

When the editor is hosted inside a Shadow DOM, mouse moves could make the global mouseleave recovery think the pointer left the editor as soon as the event target falls outside the light-DOM container. This erroneously fires mouseLeave, which can break hover/selection behavior even though the pointer is still visually over the editor.

Fix:

In the global mousemove recovery path, when the event target is outside the light-DOM container, we now query shadowRoot.elementsFromPoint and ensure none of the hit elements belong to the editor before emitting mouseLeave. This keeps the monitor active but only triggers leave when the pointer truly exits the editor, including Shadow DOM embeddings.

Fixes monaco issue: microsoft/monaco-editor#3409

Based on the changes requested in #166240

[Copilot]

Pull request overview

This PR fixes a bug where the editor incorrectly detects mouse leave events when hosted inside a Shadow DOM, causing hover and selection behaviors to break prematurely even though the pointer remains over the editor.

Key Changes:

• Enhanced the global mousemove recovery mechanism to properly handle Shadow DOM scenarios by checking elementsFromPoint when the event target falls outside the light-DOM container
• Prevents spurious mouseLeave events when the pointer is still visually within the editor's Shadow DOM boundaries

[nick-romano]

@hediet could you please review, this has been a issue for well over a year.