docs(omny): note follow-up to tighten tomo-parameter ranges + CLI validation

Not implemented for omny yet -- records the range tightening and _get_val()
min_/max_ enforcement just done for flomni/lamni (2026-09-19), and confirms
omny's parameter names mirror flomni's exactly. Also confirms tomo_params.py
has no "omny" SETUP_PROFILES entry -- omny doesn't use that shared GUI
widget at all today, so there's nothing to tighten there until its actual
parameter-entry UI (if any) is located.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0132KBoxsovfcMNRGJhS1Pbw

csaxs_bec/bec_ipython_client/plugins/omny/AI_docs/TODO_tighten_tomo_parameter_ranges.md

@@ -0,0 +1,62 @@
+# TODO: tighten tomo-parameter ranges + enforce them in the CLI wizard
+
+Status: **not implemented for omny.** Discussed and implemented for Flomni
+and LamNI on 2026-09-19 — this note exists so the same pass isn't forgotten
+for omny.
+
+## What was done for Flomni/LamNI
+
+Two separate things, both worth doing here too:
+
+1. **Tightened several parameter ranges** that had grown far looser than
+   practically useful (GUI spinbox ranges in `tomo_params.py`, plus the
+   matching property/CLI bounds where they existed):
+   - `tomo_shellstep`: 0.001–1000.0 → **0.025–20.0 µm**
+   - `stitch_x`/`stitch_y`: 0–50 → **0–10** (flomni only — lamni's own
+     `lamni_stitch_x`/`y` were left at 0–50)
+   - `golden_ratio_bunch_size`: 1–10000 → **1–100**
+   - `tomo_stitch_overlap`: 0.0–50.0 → **0.0–10.0 µm**
+   - `manual_shift_y` (flomni): -1000–1000 → **-50–50 µm**
+   - lamni-specific: `tomo_circfov` 0.0–200.0 → **0.0–500.0 µm** (floor kept
+     at 0.0 — `fov_circular == 0` means "disabled", checked explicitly in
+     `lamni_fermat_scan.py:484`, so don't raise the floor above 0);
+     `lamni_piezo_range_x`/`y` 0.0–200.0 → **0.0–80.0 µm**, matching the
+     "(max 80)" already printed in lamni's CLI prompt text.
+
+2. **`_get_val()` (the `tomo_parameters()` CLI wizard's input helper) now
+   supports `min_`/`max_`** and re-prompts until the value is in range,
+   instead of accepting anything of the right type with zero validation.
+   Both Flomni's and LamNI's `_get_val()` got this treatment (they're
+   separate static methods, not shared code) and every prompted field that
+   has a GUI-defined range got the matching `min_`/`max_` wired in.
+
+## What's needed for omny
+
+Omny has its own `tomo_parameters()` and `_get_val()`
+(`csaxs_bec/bec_ipython_client/plugins/omny/omny.py:1293` /
+`omny.py:1422`) — same bare/unvalidated pattern Flomni and LamNI both had
+before this pass. Confirmed (2026-09-19) that omny's parameter names mirror
+**flomni's** naming exactly, not lamni's: `fovx`/`fovy`, `manual_shift_y`,
+`tomo_type`, `stitch_x`/`stitch_y`, `tomo_stitch_overlap`,
+`golden_ratio_bunch_size`, `tomo_shellstep`, `tomo_countingtime` all exist
+under those same names in `omny.py`. So the flomni numbers above likely
+carry over directly, but this hasn't been checked against omny's own
+physical setup/hardware constraints (e.g. its FOV/shellstep/piezo range may
+have different practical limits than flomni's cryo ptycho setup) — don't
+just copy the numbers blind.
+
+Steps, mirroring what was done for flomni/lamni:
+1. Confirmed (2026-09-19): `tomo_params.py`'s `SETUP_PROFILES` dict has only
+   `"flomni"` and `"lamni"` entries — **no `"omny"` profile exists**, so
+   omny doesn't use this shared Tomo Parameters GUI widget at all right now.
+   Whatever GUI (if any) omny actually uses for entering these parameters
+   needs to be located first; there's nothing to tighten in `tomo_params.py`
+   for omny today. (Separately, `omny_webpage_generator.py` was confirmed in
+   an earlier session to be dead/unwired code — not related to this GUI
+   question, just don't confuse the two when investigating.)
+2. Add `min_`/`max_` support to omny's own `_get_val()` (same mechanism,
+   copy-pasted independently — these are three separate static methods, not
+   shared code, by design in this codebase).
+3. Confirm with whoever runs omny scans what the actual practical ranges
+   should be for omny's hardware, rather than assuming flomni's numbers
+   apply unchanged.