feat(tui): set the order the account list draws in

[rikbrown]

The problem

A new account is appended to accounts, so it lands at the bottom of the TUI's
list and stays there. The only way to move it was to hand-edit the accounts
array — which is the one edit that array does not tolerate. A manager index
addresses an account in route pins, session pins, currentIndex, TC_ACCT and
the disable/switch CLI paths, so permuting the array silently repoints every one
of them at a different account. _keySelect's own comment says as much.

priority looks like the answer and is not. It is rotation preference, read
throughout account-manager.js at selection time and with its own CLI command.
The order a fleet reads well in and the order it should be spent in are
different questions: a fleet usually carries exactly one non-default priority —
a deliberately deprioritised local backend — and nobody wants tidying the
display to re-rank routing. So one of the two orders was controllable from the
UI and it was the wrong one.

The design

An explicit per-account display field, displayOrder, that _displayOrder()
sorts the rows by. The array is never permuted; every index everything else
holds keeps naming the account it named.

• Settings → Reorder accounts opens the account list with ↑/↓ picking an
  account and ←/→ moving that account up and down. selIdx names the
  account being dragged, so the cursor rides with it rather than with the row
  number. Each move is saved as it is made, which is why Enter and Esc both
  just leave — there is no pending change for one to commit and the other to
  discard, and offering "cancel" would promise an undo this screen does not have.
• priority is untouched. Nothing in this branch writes it. A test asserts
  that, on the account, on its config entry, and in everything the save puts on
  disk.
• No migration. An account with no displayOrder has never been placed and
  sorts after every account that has one — which is exactly where a new account
  appeared before this existed. An existing install sees no reshuffle on
  upgrade. The comparison is ra === rb ? a - b : ra - rb rather than
  ra - rb || a - b on purpose: two Infinity ranks subtract to NaN.
• feat(tui): draw locally-served accounts last #376 still wins. Locally-served accounts are drawn last because a
  translating proxy in front of another vendor is infrastructure rather than a
  seat to rotate between — a category, not a preference. _displayOrder() still
  partitions on isLocalUpstream before it looks at the arrangement, those
  accounts are never given a displayOrder, and the reorder cursor steps over
  the rows it cannot move.
• Round trip. makeAccount normalises the field (a non-finite value reads as
  unplaced), syncAccountsFromDisk carries a hand edit onto the running account
  on reload the way a priority edit already is, and the value survives
  mergeAccountsForSave — the merge is where a field the module does not know
  about gets dropped, so a reorder that vanished on restart would have looked
  like the TUI never saved it.

What changed

File
src/account-manager.js	displayOrder on the account built from a config entry, normalised, null when unset
src/sync-accounts.js	a disk edit to it applies on reload
src/tui.js	listRank, the sort in _displayOrder(), _arrangeable(), _doMoveAccount(), the settings row, the reorder select mode and its footer
test/tui-reorder.test.js	17 cases, most of them asserting what did not change
docs/accounts.md, docs/usage.md, docs/configuration.md	the screen, its keys, and the field beside priority

Checks

npm test test/ — 1882 pass, 0 fail. npm run lint and npm run typecheck
clean. node scripts/typecheck-strict.mjs --base 7b1e92d0 — 1831 diagnostics on
both sides, no file grew.

🤖 Generated with Claude Code