[StevanusPangau]

Summary

Fixes the provider connection reorder (▲/▼) on the provider detail page: the requested order is now persisted correctly on every move, and the UI no longer shows an order that failed to save.

Also fixes the long-standing report in #329 ("can only switch accounts up, not down"), which was auto-closed as not_planned in May 2026 without a fix. This PR supersedes the diagnostic part of that report.

Root cause

handleSwapPriority in src/app/(dashboard)/dashboard/providers/[id]/page.js:

1. 0-based vs 1-based priority collision — the client wrote raw array indices (priority: index1/index2) for only the swapped pair. Stored priorities are 1-based (server assigns max+1 on create and renumbers 1..N in reorderInTx), so every swap also collided with an untouched row's priority.
2. Nondeterministic tiebreaker — reorderInTx orders by priority ASC and breaks ties by updatedAt DESC. The two PUTs were sent via Promise.all, so which write ended up "most recent" decided the final order. Consequence: moving a row up one position frequently promoted it all the way to the top (or did nothing), depending on commit order — matching the "sometimes it works" reports.
3. res.ok never checked — if either PUT failed (expired dashboard session, transient 5xx), the optimistic UI kept showing an order that was never persisted, with no refetch.

Minimal repro (5 accounts, priorities 1–5), move row 3 up one position:

• old code writes {c2: 1} and {c1: 2}; row c0 still holds priority 1 from before
• after the server flush, order becomes c2, c0, c1, c3, c4 instead of c0, c2, c1, c3, c4

Fix

• New pure helper buildPriorityUpdates(next) (same directory pattern as the existing utils.js helpers): emits { id, priority } writes carrying the final 1-based position of every row — not only the moved ones. Writing every row also covers stored duplicate priorities (bulk imports can create ties): with ties present, the server re-breaks them by most-recently-updated on each PUT, so a changed-rows-only strategy lets skipped tied rows drift to positions the user did not ask for (measured divergence: 440/572 single-move cases on tie-heavy shapes).
• Writes are sent sequentially in ascending position order. This is load-bearing: the server renumbers 1..N after every PUT and breaks ties by most-recently-updated. Ascending order keeps each write's target position valid in every intermediate state. (Parallel writes only have that guarantee for move-to-top; the tests verify all single moves converge.)
• res.ok is checked per write; local state is synced after the writes; any failure refetches from the server to roll back the optimistic UI, and new moves are gated until that refetch lands.
• Rapid clicks are serialized through a queue that reads the latest optimistic order via a ref mirror (not a render snapshot), and a row-identity guard protects against a delete landing between queueing and running a queued move.

Testing

• New tests/unit/provider-swap-priority.test.js (vitest, 7 tests) with an executable model of the server's order/renumber/tiebreak behavior (reorderInTx semantics):
  • every possible single move lands exactly (all from→to pairs, sizes 2–8, pristine priorities)
  • every single move also lands when stored priorities contain duplicates ([1,3,1], alternating [1,3,1,3,1], all-equal, [2,2,2,5], mixed) — including the minimal [1,3,1] middle→last case that diverged under a changed-rows-only strategy
  • consecutive rapid moves land (each applied against the previous result)
  • the Minimal Bugs #329 legacy-parallel behavior is reproduced (red) and fixed (green)
• npx vitest run before/after this change: identical failure set (pre-existing failures are live-credential smoke tests); no new failures introduced.

Checklist

• No changes to server-side API or DB schema — dashboard UI + tests only
• Follows existing patterns (utils.js pure helpers, tests/unit/ vitest)
• No secrets, no unrelated refactors