fix(desktop): a profile restores both panes where you left them

[ralyodio]

A profile stored source and destination, and loading put the source into the left pane always. But with the arrow pointing right-to-left the source is the right pane — so a profile saved that way came back mirrored, each pane on the wrong side, with the arrow reset to left-to-right.

Fix

source and destination still carry the transfer's meaning and always will: that is what diskpush profile run acts on, and it must not depend on how a window happened to be arranged.

So the arrangement is recorded alongside it — sourcePane, 'left' or 'right' — and loading puts each pane back where it was, arrow included.

Migration 005 adds the column defaulting to 'left', which is what every existing row was implicitly assumed to be. Nothing already saved changes behaviour.

Worth knowing while reading this

The rail's direction buttons both set the direction and start the transfer — there is no way to flip the arrow without running. So direction only ever changes as a side effect of a run, and sourcePane records the arrangement the last run used, which is the one on screen.

Caught by the type checker

The CLI's profiles save builds a profile too and didn't set the new field. It now passes 'left': a profile made from a terminal has no panes, and source-on-the-left is how the app will open it.

Verified end to end

By driving the built renderer, not by reading:

1. Flip the arrow so the right pane is the source
2. Save as pull-from-web01 — stored row reads sourcePane: right
3. Disturb the layout (flip back to left-to-right)
4. Load the profile

  left pane:   This computer
  right pane:  web-01
  arrow points right-to-left again: YES

Before the fix, step 4 put web-01 on the left.

517 tests, typecheck and pnpm smoke:desktop green.

Independent of #27 (the server manager) — both branch off main and touch different parts of page.tsx.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UeSWg1Czsb2Lwxj8vHUnA4