fix(studio): the Shift+drag edit popover stays on screen when the timeline sits low

[MannXo]

What

The Shift+drag range edit popover (EditPopover) now renders through createPortal(..., document.body), so it shows up wherever the timeline panel sits.

Why

EditPopover positions itself with position: fixed and viewport coordinates (anchorY is the pointer's clientY), but it rendered inline inside the timeline panel. Dockview's .dv-render-overlay around that panel is transformed, which makes it the containing block for fixed descendants, so the popover was placed relative to the panel instead of the window. With the default layout at 1080p it landed below the window and could not be seen.

Related work

Fixes #5376

How

Wrap the popover in createPortal(..., document.body), which is what the other timeline overlays already do (ClipContextMenu, KeyframeDiamondContextMenu, TrackGapContextMenu, AudioGainDialog, AutomationSelectionMenu, TimelineFxButton). The outside-click and Escape handlers keep working because they go through the popover's ref and window.

The issue also suggests clamping top to innerHeight. Once the coordinates resolve against the viewport, top is anchorY - 280 with anchorY inside the window, so the popover cannot start below the bottom edge and the clamp would never apply. I left it out.

The shared ui/Popover is anchored to a trigger element, and this popover opens at the end of a drag with no trigger, so it stays a plain portal like its siblings.

Test plan

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable)

• Comments follow CONTRIBUTING.md "Comments": they say why, not what, and a bug fix says what the code must do and how to reproduce the bug

• New EditModal.test.tsx renders EditPopover inside a transformed container and asserts the popover is not inside it. It fails without the change. happy-dom does no layout, so the clipping itself is checked in a browser below.

• bun run --cwd packages/studio test (695 files, 7866 tests), bun run --cwd packages/studio typecheck, bun run lint, oxfmt --check, node scripts/check-comment-citations.mjs and node scripts/comment-ratchet.mjs all pass.

• In a browser, with Studio dev on the fade-handles fixture at 1920x1080, I Shift+dragged on the timeline lane (pointer at y=850). Before the change the popover's style.top was 570px, but it rendered at 1330px, entirely below the 1080px window. After it, the popover renders at 570px above the timeline and its textarea takes clicks.

Before:

After:

[jrusso1020]

What I checked:

• Outside-click and Escape still work after the move: they go through popoverRef.contains and window listeners. React synthetic events still reach the timeline container's handlers through the portal, as before.
• Studio src/player/components/ tests: 142 files / 1816 passed at this head, and 142 / 1818 on a local merge with current main (merges cleanly; main's dash-free copy in this file is kept).
• Mutation: with the portal reverted, the new EditModal.test.tsx fails (expected true to be false), so it guards the fix.
• Agreed on leaving out the clamp. With viewport coordinates, top = max(8, anchorY - 280) can't start below the window.

Unrelated, pre-existing note for a possible follow-up: the outside-click listener is added in a 100ms setTimeout (EditModal.tsx:80), so an unmount inside that window leaks the listener.

— Rames