docs(ids-cameras): record round-4 HW-testing findings in the exposure/gain plan

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

docs/plans/ids-camera-manual-exposure.md

@@ -423,3 +423,31 @@ Two more findings:
   slider value straight to the driver — so the widget doesn't need to know about the
   discrete list itself; it just gets a corrected value back on the next
   `device_read_configuration` message, same round-trip pattern as everything else here.
+
+## Addendum: HW-testing findings, round 4 (2026-09-14)
+
+Round 3's server-side snap-to-nearest fixed what actually got *written*, but the
+slider itself still let an operator drag to (and briefly display) any integer in
+[min, max] before self-correcting on the next status message — reported as "the
+pixel clock slider still allows for any integer setting and not the specific ones".
+That's a worse interaction than just rejecting bad values: the operator sees the
+slider land somewhere it can't actually stay.
+
+Fixed by making `pixel_clock_slider` index-based over the real discrete list instead
+of ranged over `[pixel_clock_min, pixel_clock_max]`:
+
+- `OMNY_XRayEye` fetches `get_pixel_clock_list()` once over RPC at widget startup
+  (`_init_pixel_clock_options()`, `QTimer.singleShot(0, ...)` alongside the widget's
+  other one-time init calls) — this list is static per camera, so a one-time call is
+  the right trade-off versus adding a whole new signal/subscription path for something
+  that never changes at runtime. The slider is disabled until this arrives.
+- The slider's range becomes `[0, len(options)-1]`; its *position* is an index into
+  `self._pixel_clock_options`, so every position it can physically be dragged to
+  (`pixel_clock_submitted()`) is one the hardware has already confirmed it accepts —
+  no more relying on a post-hoc correction the operator has to notice.
+- `getting_camera_status()`'s pixel_clock handling now maps the hardware-reported MHz
+  value to the *nearest* option's index (`_set_pixel_clock_display()`) rather than
+  setting the slider to a raw MHz value directly.
+- `pixel_clock_min`/`pixel_clock_max` signals are unchanged on `IDSCamera` (still
+  informational, still seeded on connect) but are no longer read by the widget, which
+  no longer needs a numeric range at all.