sl0p: preview pane reordering live while dragging

Dragging showed only a green border on the target. The swap is now applied as
you drag, so the real layout IS the preview and releasing just keeps it.
Dragging elsewhere undoes it and previews the new arrangement; dragging off all
panes restores the original.

Because swap_panes is symmetric, applying it twice is the identity, so 'undo
the preview' is just the same call again. Drop needs no work at all now - the
swap already happened - which also removes the old drop-time swap.

THE TRAP, which a naive version hits immediately: once the swap is applied the
dragged pane sits under the cursor, so the next motion computes the dragged
pane as its own target, undoes the swap, which puts the original pane back
under the cursor, which re-applies it - oscillating on every motion event and
spamming both PTYs with resizes.

Avoided by treating two cases as 'the layout already shows what you would get'
and doing nothing:
  - the cursor is over the dragged pane, wherever the preview has moved it;
  - the cursor is over the pane it is currently swapped with, which after a
    preview sits at the dragged pane's original position.
So a swap is only re-applied when the cursor reaches a THIRD pane, which also
keeps PTY resizes down to one pair per target change rather than per event.

The dragged pane is kept highlighted rather than the target, so it stays
identifiable while the layout moves around it.

Note: the state machine lives in the executor and needs a real Tab, so it is
reasoned through in the commit and README rather than unit-tested; the
decision-level tests cover only which action is produced.

Baselines held: zellij-server 1441/30.

1 files changed, 6 insertions, 6 deletions

diff --git a/README.md b/README.md
index 3cc4f856..cfc1e4d1 100644
--- a/README.md
+++ b/README.md
@@ -71,13 +71,13 @@ handles, so two-axis resize from the top still works. Plain top-edge resize is g
 which costs nothing in practice: every boundary is shared, so the boundary above a
 pane is the bottom edge of the pane above it and can be dragged from there.
 
-While dragging, the pane the drop would land on is highlighted with the theme's
-`frame_highlight` colour. Hovering back over the pane being dragged shows NO
-highlight, because dropping onto itself does nothing - the absence of a highlight
-is the signal that releasing there changes nothing.
+The reordering is previewed LIVE: the swap is actually applied as you drag, so the
+real layout shows what you would get, and releasing simply keeps it. Dragging away
+undoes the preview and restores the original arrangement. The pane being dragged
+stays highlighted so it remains identifiable as the layout moves around it.
 
-Dropping a pane on itself is a no-op, so a plain click still just focuses, and
-double-click-to-rename still works. Stacked panes are excluded — in a stack the
+A drag that never leaves its own pane previews nothing, so a plain click still just
+focuses and double-click-to-rename still works. Stacked panes are excluded — in a stack the
 title row is how you focus a member.
 
 ### Double-click a pane title to rename it