fix(transfer): never leave a moved tab open in both windows

[PathGao]

Summary

A tab transfer may only end two ways: the source still has the tab, or the destination does. Four paths produced a third state — present in both, each copy with its own auto-save timer writing over the other, last writer wins.

The source's timeout ignored what the destination was doing. After 15 s it cancelled unconditionally, but 15 s is a guess about a window that may simply be slow to render a large document. cancel_detached_tab now reports whether the payload was already claimed, and the source keeps waiting for tab-transfer-claimed when it was. A claimed transfer is correspondingly immune to the source's cancel, so the race cannot go the other way either.

Nothing released a claim that could not be completed. Since the source can no longer cancel a claimed transfer, the destination is the only party able to end one — and it never did. An invalid payload, a refusing destination and a thrown render now all hand the claim back so the source recovers its tab.

A failed render left the tab inserted. The tab has to exist before it can be rendered, so the destination owns the document while the source still shows it. That window is closed by undoing the insert on any failure.

The menu could stage the same tab twice. The entry becomes clickable again long before the transfer resolves; a second click staged a second payload, two windows each claimed one and built the tab, and the source removed it once. In-flight transfers are now tracked per tab.

Broker hardening

Tokens were sequential — t1 through t16 — and every command was unauthenticated. Any webview could enumerate them:

await invoke('claim_detached_tab', { token: 't1' })  // full document text of a drag in progress
await invoke('cancel_detached_tab', { token: 't1' }) // destroy another window's transfer

Tokens are now unguessable, and each operation is bound to the window entitled to perform it: the destination is window-<token>, cancellation is the source or that destination and nobody else. Eviction under pressure drops the oldest unclaimed entry rather than whatever is oldest, so a transfer mid-handoff is never discarded — a test caught the naive version evicting the transfer that had just been staged.

Validation

• npm run check — 0 errors, 0 warnings
• npm test — 170/170, including a new scripts/tabTransferHandoff.test.ts covering each of the four paths above
• cargo test — 40/40, covering repeat claims, claims from the wrong window, cancel authority, claim-then-complete, and eviction with everything claimed