quality_control crashes on recordings with saturation events: get_times() gets called with start_frame/end_frame

Hello,

The `quality_control` step fails on some recordings with saturation. That blocks `quality_control_collector` and marks the whole pipeline FAILED.
Sorting, curation, results_collector and visualization all complete normally, so curated/, postprocessed/ and spikesorted/ are written. Only the QC report is lost.

```
File "capsule/code/run_capsule.py", line 257, in
metrics_event = generate_event_qc(
File "capsule/code/qc_utils.py", line 772, in generate_event_qc
evt_time = recording.get_times(segment_index=segment_index,
start_frame=sample_index, end_frame=sample_index+1)[0]
TypeError: BaseRecording.get_times() got an unexpected keyword argument 'start_frame'
```

**Cause**

`qc_utils.generate_event_qc` calls get_times() with frame bounds, but in SpikeInterface 0.104.8 the signature is:

```
BaseRecording.get_times(self, segment_index=None) -> np.ndarray
```
There are two call sites like this, in the positive- and negative-saturation-event branches (~lines 772 and 780).

**Trigger**

Only recordings where saturation events were detected (len(pos_evts) > 0 or len(neg_evts) > 0).
I hit it consistently on electrical-stimulation recordings, where the stimulus artifact saturates the amplifier.
Recordings without saturation never reach the line.

**Environment**

aind-ephys-pipeline 1.3.2 (HEAD 1.3.2-2-gc677469)
QUALITY_CONTROL_COMMIT=f87632c128646abde5876ca5b6823d150962bdeb
SPIKEINTERFACE_VERSION=0.104.8
SLURM backend, split_segments: false (multi-segment recording)

**Possible fix**

The surrounding comment says the intent is "To avoid loading all timestamps in memory, we lazily load the timestamps one by one", and SpikeInterface already provides exactly that:

`evt_time = recording.sample_index_to_time(sample_index, segment_index=segment_index)`

There's a possible second issue at the same site: the result is then used as` evt_time + t_start` with `t_start = recording.get_start_time(segment_index)`. `sample_index_to_time()` delegates to the segment and already returns a time including `t_start`, as does `get_times()`, so where` t_start` is non-zero this looks like it double-counts.