docs/document tomo_queue_reacquire and tomo_queue_resume

Add both to the tomo-queue command reference in flomni.md and
lamni.md: tomo_queue_resume() as an alias for tomo_queue_execute(),
and tomo_queue_reacquire(job_index, projection_number) for reopening
a job (including an already-"done" one) at an earlier projection and
cascading later jobs to pending, mirroring the code added in the
previous commit.

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

docs/user/ptychography/flomni.md

@@ -345,6 +345,7 @@ Several tomo parameter sets can be queued and run sequentially on the same sampl
 | `flomni.tomo_queue_delete(*indices)` | Delete one or more jobs by index. |
 | `flomni.tomo_queue_clear()` | Empty the queue. |
 | `flomni.tomo_queue_execute(start_index=0)` | Run all pending jobs in sequence, on the current sample. |
+| `flomni.tomo_queue_resume(start_index=0)` | Alias for `tomo_queue_execute()` — identical behavior, just a name that matches `tomo_scan_resume()`. |
 
 The queue is persisted (it survives a BEC client restart). Each job's status is one of `pending`, `running`, `incomplete`, or `done`. A job that did not run to completion (an exception was caught, or the BEC client itself crashed mid-scan) is automatically resumed - rather than restarted - the next time `flomni.tomo_queue_execute()` is called.
 
@@ -375,6 +376,38 @@ open in the panel. If you have an unsaved edit open and click the queue window's
 button instead of the panel's, it warns and names the correct one before proceeding,
 since it would otherwise queue your last-submitted values, not what you just typed.
 
+**Reacquiring from an earlier projection.** A resumed job normally picks up
+exactly where it stopped. If a beamline problem means earlier projections need
+redoing too — even in a job that's already marked `done` — use:
+
+`flomni.tomo_queue_reacquire(job_index, projection_number)`
+
+`job_index` is the job's position, same indexing as `tomo_queue_show()`.
+`projection_number` is a flat, 0-indexed projection count that works the same
+way for all three tomography modes — for "8 sub-tomograms" it counts straight
+through all 8 in order (subtomogram 1's projections first, then subtomogram
+2's, ...), exactly matching the running `projection` counter already shown in
+the live progress report / `flomni.progress["projection"]`; for the
+golden-ratio modes it's the same projection number those already use. This
+reopens the job at that point and resets every job queued *after* it —
+tomograms and command jobs alike, regardless of their own current status — to
+`pending`, so the next `flomni.tomo_queue_resume()` (or `tomo_queue_execute()`)
+call re-runs everything from there forward, in order. It does not run
+anything itself.
+
+Example — job 0 already finished, but its last few projections (and the jobs
+queued after it) need redoing:
+```
+flomni.tomo_queue_show()               # find the job index and the projection number to restart at
+flomni.tomo_queue_reacquire(0, 130)    # reopen job 0 at projection 130; jobs 1+ reset to pending
+flomni.tomo_queue_resume()             # actually re-run, in order
+```
+
+Refuses (raises) if `job_index` points at a command job (nothing to
+reacquire), or if some *other* job in the queue is already `incomplete`/
+`running` — only one job's progress can be tracked at a time, so resolve that
+one first (or pass its own index instead).
+
 #### Command jobs — reconfiguring the beamline between scans
 
 In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered

docs/user/ptychography/lamni.md

@@ -113,6 +113,7 @@ Several tomo parameter sets can be queued and run sequentially on the same sampl
 | `lamni.tomo_queue_delete(*indices)` | Delete one or more jobs by index. |
 | `lamni.tomo_queue_clear()` | Empty the queue. |
 | `lamni.tomo_queue_execute(start_index=0)` | Run all pending jobs in sequence, on the current sample. |
+| `lamni.tomo_queue_resume(start_index=0)` | Alias for `tomo_queue_execute()` — identical behavior, just a name that matches `tomo_scan_resume()`. |
 
 The queue is persisted (it survives a BEC client restart). Each job's status is one of `pending`, `running`, `incomplete`, or `done`. A job that did not run to completion (an exception was caught, or the BEC client itself crashed mid-scan) is automatically resumed - rather than restarted - the next time `lamni.tomo_queue_execute()` is called.
 
@@ -149,6 +150,37 @@ of the queue, labeled with `_dup` appended, status reset to `pending`. Useful fo
 re-running a job with the same settings without re-typing them, or as a starting point
 to tweak via "Load into editor".
 
+**Reacquiring from an earlier projection.** A resumed job normally picks up
+exactly where it stopped. If a beamline problem means earlier projections need
+redoing too — even in a job that's already marked `done` — use:
+
+`lamni.tomo_queue_reacquire(job_index, projection_number)`
+
+`job_index` is the job's position, same indexing as `tomo_queue_show()`.
+`projection_number` is a flat, 0-indexed projection count that works the same
+way for all three tomography modes — for "8 sub-tomograms" it counts straight
+through all 8 in order (subtomogram 1's projections first, then subtomogram
+2's, ...), exactly matching the running `projection` counter already shown in
+the live progress report / `lamni.progress["projection"]`; for the golden-ratio
+modes it's the same projection number those already use. This reopens the job
+at that point and resets every job queued *after* it — tomograms and command
+jobs alike, regardless of their own current status — to `pending`, so the next
+`lamni.tomo_queue_resume()` (or `tomo_queue_execute()`) call re-runs everything
+from there forward, in order. It does not run anything itself.
+
+Example — job 0 already finished, but its last few projections (and the jobs
+queued after it) need redoing:
+```
+lamni.tomo_queue_show()               # find the job index and the projection number to restart at
+lamni.tomo_queue_reacquire(0, 130)    # reopen job 0 at projection 130; jobs 1+ reset to pending
+lamni.tomo_queue_resume()             # actually re-run, in order
+```
+
+Refuses (raises) if `job_index` points at a command job (nothing to
+reacquire), or if some *other* job in the queue is already `incomplete`/
+`running` — only one job's progress can be tracked at a time, so resolve that
+one first (or pass its own index instead).
+
 #### Command jobs — reconfiguring the beamline between scans
 
 In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered