fix(app): coalesce split resize previews by frame

[Juns-g]

Linked issue

Fixes #4163

Type of change

• Bug fix
• New feature
• Enhancement
• Refactor
• Docs

What does this PR do

Coalesces split-pane resize previews to at most one update per animation frame while keeping only the latest pointer position.

If the pointer is released before the queued frame runs, the drag synchronously previews and commits the latest size, cancels the queued callback, and prevents a stale callback from repainting afterward.

The persisted resize behavior and pointer-up/pointer-cancel semantics are unchanged. This PR does not add Browser- or Terminal-specific resize behavior.

Why

The desktop split handle currently previews every pointermove immediately. High-frequency pointer input can produce more resize work than the renderer can display, forcing pane contents—including browser webviews, terminals, and long conversations—to process intermediate layouts that will never be painted.

Automated verification

Regression proof against the unchanged base commit 0c38749c:

Test Files  1 failed (1)
Tests       1 failed (2)
AssertionError: expected +0 to be 1
RED_EXIT=1

Final branch:

Test Files  6 passed (6)
Tests       24 passed (24)

Commands run on Node 22.20.0:

npx vitest run packages/app/src/components/resize-handle-drag.test.ts packages/app/src/components/resize-handle-sizes.test.ts packages/app/src/components/sidebar-resize-handle-layout.test.ts packages/app/src/components/terminal-resize-debouncer.test.ts packages/app/src/terminal/native-renderer/terminal-input-resize-policy.test.ts packages/app/src/terminal/native-renderer/terminal-resize-policy.test.ts --bail=1
npm run lint -- packages/app/src/components/resize-handle-drag.test.ts packages/app/src/components/resize-handle-drag.ts
npm run format:check:files -- packages/app/src/components/resize-handle-drag.test.ts packages/app/src/components/resize-handle-drag.ts
npm run typecheck --workspace=@getpaseo/app
git diff HEAD^ --check

Results:

• 24/24 related resize tests passed.
• Changed-file lint: 0 warnings, 0 errors.
• Formatting check passed.
• @getpaseo/app typecheck passed after building the repository client declarations and applying the repository's existing dependency patches.
• Diff check passed.

Platform QA

Platform	Tested	Notes
Desktop macOS	Not yet	Draft pending before/after interaction video on the reported environment.
Desktop Windows	No	Not available.
Desktop Linux	No	DevBox verification is headless only.
Web	No	Same helper is used, but no interaction capture yet.
iOS	No	Not available.
Android	No	Not available.

Risk surface

The change is limited to the split drag helper and its unit test. Browser, terminal, persisted layout, and pointer event handling are unchanged. The remaining risk is runtime frame pacing on Electron, which is why this is opened as a draft pending macOS interaction QA.

Checklist

• One focused change
• Links the bug it fixes
• Automated regression test with red/green evidence
• Typecheck, lint, and formatting checks
• Before/after UI interaction video
• macOS Electron runtime QA

[boudra]

Closing for now: this needs before/after macOS Electron video and frame-timing evidence for fast split-divider drags with browser or terminal content. Please reopen with that evidence.

[boudra]

Please disregard the earlier invitation to reopen with evidence. This PR remains closed unless I explicitly follow up. You don't need to resubmit this PR or provide further QA evidence.

Please read the updated PR policy. For now, I'm automatically closing feature PRs so I can focus more time on bug fixes and core improvements. Focused bug-fix PRs with a clear reproduction and QA are still welcome. The previous guide already asked contributors to submit only if they were comfortable with closure, and explained that unsolicited PRs could be closed without a detailed review.

For feature ideas, please start in GitHub Discussions and share your workflow: what you're trying to do, how you do it today, and where Paseo gets in the way. If there's already a discussion about it, join in and share your use case. I'll periodically review discussions for highly requested workflows and use that feedback to shape the roadmap.

I'll periodically look through closed PRs and choose which contributions to take forward, whether solicited or unsolicited. I may reopen a PR, including one closed by mistake, or use it as a reference for my own implementation, with attribution either way.

There are hundreds of PRs alongside ongoing development. I can't commit to reviewing every submission, providing individual feedback or giving timelines.