docs(flomni): document the incomplete-job reorder floor fix

Updates plan section 6.4 and the GUI test checklist (item 5, new test
step 23a) for narrowing sort-mode/tomo_queue_move() reordering to
pending-only, with running and incomplete both acting as a floor.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md

@@ -430,16 +430,26 @@ the thing already in progress.
 drag-and-drop.** A checkable "Sort queue…" button puts the dialog into a focused
 reorder mode: other queue-mutating buttons (add/add command/delete/clear) disable,
 the table becomes single-select, and "▲ Move up" / "▼ Move down" swap the selected
-row with its neighbour. A swap is only ever between two `pending`/`incomplete` rows —
-a `running` or `done` neighbour blocks the swap outright, which gets the running-row
-floor and the done-row pinning (§6.3) for free without separate index-range
-bookkeeping. Reaching a position more than one row away takes multiple clicks, unlike
-drag-and-drop, but sidesteps implementing "reject any drop above the running row" as
-live drag-event math. Writes go straight to the `tomo_queue` global var, same pattern
-as add/delete/clear (§6.1's two-write-paths rule doesn't apply here — reordering never
-touches the live param global vars). The CLI got the equivalent
+row with its neighbour. A swap is only ever between two `pending` rows — a `running`,
+`incomplete`, or `done` neighbour blocks the swap outright, which gets the
+running/incomplete floor and the done-row pinning (§6.3) for free without separate
+index-range bookkeeping. Reaching a position more than one row away takes multiple
+clicks, unlike drag-and-drop, but sidesteps implementing "reject any drop above the
+running row" as live drag-event math. Writes go straight to the `tomo_queue` global
+var, same pattern as add/delete/clear (§6.1's two-write-paths rule doesn't apply here
+— reordering never touches the live param global vars). The CLI got the equivalent
 `tomo_queue_move(index, new_index)`, so both surfaces can reorder the pending tail.
 
+**`incomplete` is a floor too, not just `running`.** The first cut treated
+`incomplete` as movable alongside `pending`, reasoning that resume-before-fresh
+already protects the real execution order regardless of list position. In practice
+that let an operator drag a `pending` job visually ahead of an `incomplete` one —
+functionally harmless (the `incomplete` job still resumes first), but confusing to
+read, since list order looked like it meant run order and didn't. Fixed by narrowing
+`_MOVABLE_STATUSES` to `("pending",)` in the GUI and the equivalent floor check in
+`tomo_queue_move()` (blocks any `new_index` at or below the highest index among all
+`running`/`incomplete` jobs, not just the running one).
+
 ### 6.5 The command-job builder — a structured form, not a text box
 
 An **"Add command…"** control opens a sub-dialog:

csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md

@@ -63,11 +63,15 @@ support on top of it:
    enters a focused reorder mode: add/add-command/delete/clear disable, the
    table becomes single-select, and "▲ Move up" / "▼ Move down" swap the
    selected row with its neighbour. A swap only ever happens between two
-   `pending`/`incomplete` rows — a `running` or `done` neighbour blocks it,
-   which is what keeps the running job as a floor and done jobs pinned. Not
-   drag-and-drop (see section 7's old note on why that was deferred) — this
-   is the up/down-button alternative. The CLI got the same capability via
-   `flomni.tomo_queue_move(index, new_index)`.
+   `pending` rows — a `running`, `incomplete`, or `done` neighbour blocks
+   it, which is what keeps the running/incomplete job as a floor and done
+   jobs pinned. (`incomplete` was movable in an earlier pass; narrowed to a
+   floor after testing showed a pending job could be dragged visually ahead
+   of an incomplete one — harmless to actual run order, since
+   resume-before-fresh always resumes it first regardless of position, but
+   confusing to read.) Not drag-and-drop (see section 7's old note on why
+   that was deferred) — this is the up/down-button alternative. The CLI got
+   the same capability via `flomni.tomo_queue_move(index, new_index)`.
 6. **Full-detail row tooltips.** Every cell in a queue row now carries a
    tooltip with the complete job detail — label, status, added-at, and
    either the full params dump (tomo job) or the numbered step list +
@@ -219,6 +223,14 @@ file is exactly how a regression sneaks in.
 23. If any job in the queue is `done`, select a `pending` row adjacent to
     it and confirm the move button on that side is disabled — done rows
     are pinned, not swapped past.
+23a. Get a job to `incomplete` (stop a running scan, or let one raise) and
+    leave it in the queue. In sort mode, select it and confirm both move
+    buttons are disabled (it can't be moved itself). Select the `pending`
+    row directly after it and confirm "Move up" is disabled too — a
+    pending job must never be draggable ahead of an `incomplete` one, even
+    though `tomo_queue_execute()` would still resume the incomplete job
+    first regardless (this was a real gap found during testing: the first
+    pass let `incomplete` swap freely with `pending`).
 24. Click **"Sort queue…"** again to leave sort mode. Confirm the other
     buttons re-enable and multi-row selection (for delete) works again.
 25. Cross-check from the CLI: with the queue back in a known order, run