Doric preflight-armed driver is reused at runtime but stimulation startup still calls connect()

Leggi preflight_ui.py::_arm_laser_for_launch(), quindi segui stim_controller.py::from_config() e start() per tracciare il riutilizzo di live_state.laser_driver. Controlla doric_light_source.py::connect() e gli esempi del ciclo di vita di Doric inclusi. Il lavoro è completato quando il percorso preparato dal preflight è esplicito, salta una seconda connect() e distingue il riutilizzo dalla nuova inizializzazione senza modificare il blocco dell'avvio.

Summary

When a laser run is verified in preflight, we keep a live DoricLightSource in live_state.laser_driver and reuse it during runtime. However, StimulationController.start() still unconditionally calls driver.connect().

Why this is confusing

• Preflight launch verification already opens the Doric device and leaves it armed.
• Runtime reuses that same driver object via live_state.laser_driver.
• start() still calls connect() as if runtime owns first initialization.
• This currently works only because DoricLightSource.connect() short-circuits when self._dll is not None.

Code references

• preflight_ui.py: _arm_laser_for_launch() stores the armed driver in live_state.laser_driver.
• stim_controller.py: from_config() reuses live_state.laser_driver when present.
• stim_controller.py: start() still calls self._config.driver.connect() unconditionally.
• doric_light_source.py: connect() returns early when _dll is already set.

Local evidence

• Bundled Doric examples show a single lifecycle: init -> open_device -> use -> close_device -> quit.
• We did not find local documentation explicitly stating that repeated connect() on an already-open device is supported.
• In the current reuse path, the second connect() is probably harmless because our wrapper short-circuits, but that is wrapper behavior, not a documented Doric contract.

Desired fix

• Make the preflight-armed runtime path explicit.
• Do not call connect() again when reusing an already-armed preflight driver.
• Keep runtime startup semantics clear: reuse vs fresh initialization should be distinguishable in code and UI copy.

Notes

• This is separate from UI wording cleanup.
• Preflight still blocks launch if required laser verification fails.
• After launch, runtime fault handling remains a separate behavior question.