Native dragstart never fires when a modifier key (e.g. Shift) is already held down before the drag gesture starts

[yevhen330]

Describe the bug
If Shift (or another modifier key) is already held down before the mouse button is pressed to start dragging a tree item, the native HTML5 dragstart event never fires at all - the drag simply never begins. This happens with items rendered through renderItem, using context.itemContainerWithoutChildrenProps / context.interactiveElementProps (the library's own native drag wiring - draggable + onDragStart from createInteractiveElementProps), no external DnD library involved.

If the drag is started without Shift held (mouse down, move a bit) and Shift is only pressed after the drag has already begun, everything works as expected - the drag continues and dragover/drop correctly see shiftKey: true.

Confirmed via Chrome DevTools "Event Listener Breakpoints -> Drag -> dragstart": the breakpoint never pauses when Shift is held from the start of the gesture, but does pause for a normal (no-modifier) drag.

To Reproduce
Steps to reproduce the behavior (using the official Storybook, no external DnD library):

Step 1: Open https://rct.lukasbach.com/storybook/?path=/story/core-custom-renderers--minimal-renderers
Step 2: Press and hold Shift.
Step 3: While still holding Shift, press the mouse button down on any tree item and try to drag it.
Step 4: Nothing happens - no drag preview, no drop indicators, dragstart never fires.
Step 5: For comparison - release Shift and repeat steps 3-4 without it held; dragging works normally. Or: start the drag without Shift, then press Shift mid-drag; this also works fine (drag continues, doesn't restart).

Expected behavior
Dragging should start the same way regardless of whether a modifier key happens to already be held down at the moment the gesture begins.

Additional context
We have the exact same symptom in our own app for a tree built with ControlledTreeEnvironment + a custom renderItem, which made us initially suspect our own drag implementation. However, the Storybook example above - which uses react-complex-tree's own native drag-and-drop, no external DnD library involved - reproduces the identical behavior, which points to this being a react-complex-tree issue rather than something specific to a consuming app's renderItem/DnD setup.

We spent a while ruling out other explanations before landing here: it's not native browser text-selection stealing the gesture (no selection is ever created), it reproduces across browsers/incognito (not an extension or OS-level modifier feature), and it's not caused by useHotkey's partial-combo-match preventDefault() on bare modifier keydowns (we patched that locally and the symptom was unchanged). At this point the most likely remaining explanation is something in how draggable/onDragStart get wired up through renderItem's interactiveElementProps, but we haven't pinned down the exact mechanism.

• OS: macOS
• Browser: Chrome (also reproduces in other browsers)
• Version: 2.6.0