feat: stagger per-FOV min_start_time in apply_fov_batching

[hinderling]

What

apply_fov_batching gains an offset_min_start_time parameter (default True).

When FOVs overflow a batch, they are split into batches imaged in sequence. But within a batch the FOVs are also imaged one after another, not simultaneously — the k-th FOV of a batch only begins ~k * time_per_fov after the batch's first FOV. Previously every FOV in a batch shared the same min_start_time, which did not reflect that.

offset_min_start_time=True staggers each event's min_start_time by (within-batch slot) * time_per_fov, where the within-batch slot is the FOV's sorted position modulo n_parallel. The first FOV of each batch keeps a 0 within-batch offset; batches after the first still get their batch wall-clock offset on top.

Why

• The scheduled per-FOV frame interval now matches how the hardware actually visits FOVs (sequentially within a batch).
• It makes lag measurement meaningful. Lag is acquisition-start − min_start_time. With every FOV in a batch sharing one min_start_time, FOVs 2..k looked increasingly "late" simply because they were imaged later by design. Encoding the real schedule into min_start_time removes that artifact, so lag reflects genuine drift rather than batch ordering.

Behavior notes

• Default True; pass offset_min_start_time=False for the previous shared-min_start_time behavior.
• A single batch (n_fovs <= n_parallel) is no longer a strict no-op when offset_min_start_time=True — the within-batch stagger still applies. With offset_min_start_time=False it remains a no-op.

Test plan

• Single batch, time_per_fov=3: p0 → +0, p1 → +3, p2 → +6.
• Multi-batch: the within-batch slot resets to 0 at each batch boundary; the per-batch wall-clock offset still applies on top.

[hinderling]

Recreated against the upstream repo pertzlab/faro: pertzlab#13