docs(eiger): record that triggering emulates gating, and why

The Eiger is triggered rather than gated for stability, and the pulse train is
shaped so its internal timer coincides with the gate -- it is meant to behave as
if gated, so that every detector in a scan integrates the same window. Nothing
in the code said so, which is why sending the full exp_time as image_time_us
looked reasonable and stayed wrong until a scope showed the 173 us overhang.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KLnmUurqcNd1FiDY5M2uZr

csaxs_bec/devices/jungfraujoch/eiger.py

@@ -13,6 +13,12 @@ A few notes on setup and operation of the Eiger detectors through the JungfrauJo
   budgets 20 us of board readout between frames, which is right for 16 bit parallel mode but far
   smaller than the subframe granularity -- so a frame can outlast the trigger period without
   anything reporting an error.
+- The Eiger is TRIGGERED rather than gated (DetectorTiming.TRIGGER), for stability: gating
+  it proved unreliable. It therefore ignores the gate width and runs its own timer from the
+  rising edge. The pulse train is deliberately shaped so that this timer coincides with the
+  gate -- the Eiger is meant to behave *as if* it were gated, so that every detector in the
+  scan integrates the same window. Sending it anything other than the gated window breaks
+  that, silently, and is only visible on a scope.
 - scan_info's exp_time is the trigger PERIOD, not the exposure. The delay generator gates for
   exp_time - readout_time, and on_stage sends that same window as image_time_us so the detector
   is not still acquiring when the next trigger arrives. The readout time must agree with DDG2's