[essreduce] Pulse-stride guess counts choppers that are out of sync with the source #781

guess_pulse_stride_from_choppers derives the stride from every active chopper, including one that close_non_synced_disk_choppers will shut because it is not in sync with the frame. A chopper at a frequency unrelated to the source (a setpoint error) therefore sets the stride, and the inflated stride can then shut healthy choppers too.

DREAM setpoints as observed in production (scipp/esslivedata#1309), source at 14 Hz:

pulse_shaping 7 / 7, band 14, overlap 5, T0 0 Hz
-> stride round(14 / 5) = 3, frame frequency 14/3 Hz
-> closed: pulse_shaping_chopper1, pulse_shaping_chopper2, overlap_chopper

The pulse-shaping choppers are fine at stride 2 (7 / (14/2) = 1), but not at stride 3 (7 / (14/3) = 1.5). Expected: stride 2, only the overlap chopper closed.

Consequences downstream:

• The table goes blank from the first chopper instead of from the faulty one.
• A caller reporting which choppers were closed names healthy ones.
• With only the overlap chopper at 5 Hz and all others at 14 Hz, the stride becomes 3 instead of 1. A wavelength monitor workflow then fails on essreduce: event monitors cannot be converted to wavelength when pulse skipping #750, where it would otherwise convert with stride 1 and the faulty chopper closed.

Proposed fix: only a chopper whose period is a whole number of pulse periods (1 / (f * pulse_period) is whole) contributes to the guess. Choppers faster than the source already contribute nothing (round(14 / 28) = 0), so the change only affects slow choppers whose frequency does not divide the source frequency. Such a chopper is still kept if it is in sync with the stride set by the other choppers (28/3 Hz next to 14/3 Hz at stride 3), and closed otherwise.