Preflight UI should describe delay start relative to final launch confirmation, not as a fixed timestamp

Problem

In open-loop configs with stimulus.start.mode: delay, the preflight Session Summary currently renders a concrete scheduled timestamp such as 2026-06-10 13:04:53.

That is misleading at the UI level because the delay is not anchored to when the preflight screen first opened. It is anchored to the operator's final launch confirmation.

As discussed while testing a 10 minute baseline config:

• configured value: delay_seconds: 600
• current UI wording: delay 600 s -> 2026-06-10 13:04:53
• actual behavior: the 600 second delay starts after the final Launch Experiment confirmation

Why this matters

The timestamp shown in preflight is spurious because it drifts if the operator stays on the screen before launching. That makes the UI easy to misread in a safety-sensitive workflow.

Expected UI behavior

For delay-mode starts, prefer wording like:

• delay 600 s from final launch confirmation

or similar language that makes the anchor explicit.

It may also be worth making final more explicit in the launch flow text if there are multiple confirmations, for example:

• delay 600 s from final launch confirmation
• stimulation schedule begins after final launch confirmation

Likely code area

• preflight_ui.py, especially the start summary / display path for delay mode
• any related launch confirmation text that currently says only launch without clarifying that this means the final operator confirmation

Notes

Clock-based start mode should still show an absolute scheduled time. This issue is only about stimulus.start.mode: delay.

Start in preflight_ui.py, especially the start summary/display path for delay mode, and inspect any launch confirmation text that uses only “launch.” Update delay-mode wording to describe the delay from the final launch confirmation rather than a fixed timestamp, while keeping an absolute scheduled time for clock-based starts.