Summary

Fixes #2346.

On Linux with primary-selection paste enabled (the default), middle-clicking a tab to close it produced an unwanted primary-selection paste into whichever terminal became active after the close. Repro is in the linked issue.

The existing `onMouseDown` `preventDefault` on each tab blocks Chromium's middle-button auto-scroll but is not sufficient to block the native paste pipeline — that one is gated on `mouseup`. After the tab unmounts via `onAuxClick` → `onClose`, focus moves to xterm's hidden `<textarea>` on the newly active terminal, and the native paste lands there.

This applies on both X11 and Wayland sessions (the issue author confirmed Hyprland with `wp_primary_selection_unstable_v1`).

Fix

Adopt the same option-(a) approach from the issue's analysis:

• Add a small named helper `preventMiddleButtonDefault` in `src/renderer/src/components/tab-bar/middle-button-default-guard.ts`.
• Wire it as `onMouseUp` on `SortableTab`, `BrowserTab`, and `EditorFileTab` — the three tab surfaces that close on middle-click.
• Mirrors the cancel already performed by `usePrimarySelectionPaste`'s `enabled=false` branch for non-tab surfaces.

The change is tab-local and surgical: only the three components that already close on `auxclick` get the new `onMouseUp`. No global event listeners are added or modified.

No platform branching

`event.preventDefault()` on a `mouseup` event is harmless on macOS and Windows — there is no native primary-selection paste pipeline to cancel there. Avoiding a platform check keeps the surfaces consistent and follows the project's cross-platform guidance (no `navigator.userAgent` sniffing for a behavior that's a no-op off Linux).

Tests

`src/renderer/src/components/tab-bar/middle-button-default-guard.test.ts` pins the contract:

• Middle button (`button === 1`) → `preventDefault` is called.
• Left button (`button === 0`) → `preventDefault` is not called.
• Right button (`button === 2`) → `preventDefault` is not called.

(Project convention is to extract logic into named functions and unit-test those — no React rendering in tests. See `QuickLaunchButton.test.ts` for the same pattern.)

No visual change

This is pure event-handler behavior; the rendered tab markup is unchanged.

Manual verification

Manual repro requires a Linux session with primary-selection paste enabled, which I do not have available locally. The fix follows the issue author's analysis precisely and matches the working pattern in the existing `enabled=false` branch of `usePrimarySelectionPaste`. Linux verification by a reviewer / the issue author would be appreciated before merge.

Cross-platform / security review

• Cross-platform: `preventDefault` on `mouseup` for `button === 1` is a no-op on macOS/Windows (no native primary-selection paste pipeline). Behavior is unchanged there.
• SSH use case: Tab handlers run in the renderer regardless of where the underlying PTY lives, so the fix applies uniformly.
• Security: Strictly stops a spurious paste of the user's own primary-selection text into the wrong terminal. No new surfaces exposed, no new code paths in privileged processes.

CI checks run locally

• `pnpm lint`
• `pnpm typecheck`
• `pnpm test` — 8910 passed, 10 skipped. One pre-existing macOS-only flake in `src/main/startup/run-electron-vite-dev.test.ts` ("preserves relative Electron framework symlinks in the copied mac dev app") timed out at the 5000ms limit; unrelated to this renderer-only change and the test passes intermittently.
• `pnpm build`