In a Protocol with AF every Interval, the AF turns off the LED after AF and back on to acquire

[EtalumaSupport]

It would be faster to take the last frame while the AF result is achieved.

[ericweiner]

Fix shipped -- ready for bench verification

Root cause: In a protocol with AF every Interval, the AF runner turned LED off in its finally clause; capture() immediately turned LED back on at the SAME channel + illumination as the AF pass. Wasted ~50-200 ms per AF-every-N step plus an extra mechanical on/off cycle on the LED PCB. Customer's framing in the original report: "take the last frame while the AF result is achieved" -- this is Approach A, trim the off/on; the user's literal ask (Approach B, lift AF's last image as the capture image) needs a data-integrity audit and is filed separately.

Fix: modules/autofocus_runner.py::AutofocusRunner.run -- new keep_led_on: bool = False parameter. When True, finally clause skips _led_off + restore_led_state. modules/protocol_step_runner.py::scan_iterate -- passes keep_led_on=True when invoking AF (the next operation in protocol context is capture on the same color + illumination; same-color invariant holds because the BF-AF-for-fluorescence branch retires AF entirely earlier). Interactive AF runs default to False so pre-AF state still restores as before.

SHA: 1fde650 on 4.0.0-beta (current tip 1fde650, 4.0.0-beta14 build).

Regression test: tests/test_issue_612_af_keep_led_on.py (4 AST guards: signature param + default, self storage, finally if/else gate, protocol_step_runner pass-through). 71 existing AF + protocol-module tests still pass.

Retest signal:

1. Run a protocol with AF every Interval = 1 + a single BF layer.
2. Inspect api.log between AF completion and capture start. Expected: a single [AF] keep_led_on -- skipping LED off + restore line, then capture proceeds. NO leds_off between AF end and capture start.
3. Step cadence should improve by ~50-200 ms per AF-every-N step (more noticeable on a long multi-well protocol).
4. Run an interactive AF (the Focus button in the UI, not inside a protocol). Expected: pre-AF LED state restored as before -- the keep_led_on path is protocol-only.
5. Run a protocol with AF + multi-color (BF + Blue). Confirm AF still runs only on BF (per the BF-AF-for-fluor toggle) and the Blue capture is on Blue. The fix does not change the AF channel selection logic.

EtalumaSupport, please download the latest beta build and verify the fix. Then either close this issue if fully resolved, or add a note describing what is still happening.

[EtalumaSupport]

Now the LED stays ON between Steps

A1_BF_2xOly_0000.tiff
A2_BF_2xOly_0000.tiff
protocol_record.tsv
SN12064-2026-06-03-103950.zip
unsaved_protocol.tsv