Trim repetitive game ts rather than arbitrary barcodes droped at the start

[CeliaBenquet]

As discussed with @arturoptophys, there were also repeats of onset_unity_time at the end of a session (not just at the start. So the arbitrary drop at the start of a session was not sufficient. As the repeats at the end were different across sessions, we went back to removing the repeats timepoints rather than droping barcodes. This was tested on one session, same as in #343, and the overlaping increased!

that's from #343 (before correct lineage)

and that's now:

[arturoptophys]

few notes:

• Change to BarcodeSync table definition -> requires dropping and repopulation-> mention in description.

Potential fixes to Barcodes Table (but maybe different PR) which had 2 additional edge-case failures:

• analysis/barcodes.py:99 still raises teensy_time must be strictly increasing. Xestia_2026-08-11_1 remains discarded over pure duplicate rows with identical ttl_read — relaxing to non-decreasing recovers ~65 barcodes for a 302 s recording.

• align_timestamps_to_step_time still snaps out-of-range stamps to the boundary instead of NaN. The trim treats the symptom well, but the root cause is one np.where away, and fixing it there would make the trim a cheap sanity check rather than the load-bearing repair.

[arturoptophys]

Maybe suggestion for additional fields which capture the fixes/ quality better:

definition = """
-> vr_barcodes.TeensyBarcodes
-> np_barcodes.ProbeBarcodeExtraction
---
slope: float64  # Slope of the linear fit mapping VR time to NP time
intercept: float64  # Intercept of the linear fit mapping VR time to NP time
r2: float64  # R-squared of the fit. NOT a quality signal -- gate on rmse_ms
rmse_ms: float64  # RMS fit residual in milliseconds; the quality gate
max_abs_residual_ms: float64  # Largest single tie-point residual, milliseconds
n_shared_barcodes: int32  # Tie points the fit actually used
n_trimmed_leading: int32  # Leading events dropped as a repetitive onset_time_unity run
n_trimmed_trailing: int32  # Trailing events dropped as a repetitive onset_time_unity run
n_rejected_outliers: int32  # Tie points dropped as residual outliers
interpol_func: <blob>  # pickled scipy.interpolate.interp1d, VR time -> NP time
barcode_overlap: float64  # Fraction of NP barcodes also found on the VR side
"""

[CeliaBenquet]

review from artur: https://claude.ai/code/artifact/29255316-17a9-491d-ae19-874ba7142f00

[CeliaBenquet]

now with the new fields.

[lecriste]

I noticed this:

NaN onset_time_unity is produced but not handled end-to-end

dlc_helpers.align_timestamps_to_step_time now returns NaN for timestamps outside [step_time[0], step_time[-1]] (it previously clamped to the nearest endpoint). That NaN is never handled downstream:

1. schema/barcodes.py TeensyBarcodes.make inserts the aligned value as
   onset_time_unity for every event (zip(result.events, event_step_times, strict=True)).
2. onset_time_unity is float64 (non-nullable). NaN is not representable in a MySQL DOUBLE and hard-errors under strict SQL mode (the default) → TeensyBarcodes fails for that dataset.
3. Even if it were stored, BarcodeSync.make fetches onset_time_unity as vr_times with no finite filter, and the new align_barcodes validates finiteness up front
   (if n_bad: raise "... NaN or infinite ..."), before trimming/intersection — so it raises for the whole session.

The new boundary trim can't absorb these: _boundary_repetitive_run_lengths compares with !=, and NaN != NaN is always True, so NaN is never seen as a repeated run and never trimmed.

Failure scenario: a session with barcode events just before the first / after the last
step_time — i.e. the boundary events this PR is explicitly about — now yields NaN
onset_time_unity → TeensyBarcodes insert errors (strict mode), or if stored,
BarcodeSync raises on the finiteness check. So the targeted sessions can regress from "clamped boundary repeats" to a hard failure. There's no end-to-end test for this (the only NaN test is at the function level).

Fix (pick one):

• In TeensyBarcodes.make, drop events whose aligned onset_time_unity is NaN before inserting Event rows (they're out-of-game-window boundary events), or
• Make onset_time_unity nullable and have align_barcodes/make filter non-finite tie points (drop, don't raise) so the trimming + outlier logic runs on the finite set.

Either way, maybe add an end-to-end test with an out-of-range boundary event.

[lecriste]

LGTM.
I triggered the cron_scenario test:
https://github.com/MMathisLab/FreelyMovingVR4Mice/actions/runs/32151216988

[arturoptophys]

one more small nitpick

The diagnostic columns will now read 0 on every session. Clamped values become NULL, so _trim_repetitive_boundary_timebins finds no repetitive runs — n_trimmed_leading/n_trimmed_trailing will be 0 everywhere. The signal they were added to capture (how far Unity's logging lagged the Teensy: 2–17 barcodes) has moved into n_vr_dropped, which is logged but not stored.

so maybe remove n_trimmed_* replace them with n_unmapped_vr_events ? ->n_vr_dropped