Copy recording on `register_recording` to avoid shared mutation

[h-mayorquin]

BaseSorting.register_recording stores the recording by reference (self._recording = recording). Any mutation to the recording object (setting times, shifting times, setting probes, changing properties) is visible through the sorting. This makes it hard to reason about ownership: code that modifies a recording may not know a sorting is sharing it, and code that operates on a sorting may not intend to mutate someone else's recording.

I think that we should copy the recording at registration time so that it serves as a snapshot. This way, we might want to mutate something of the recording in the registration without affecting it or vice-versa. Recordings are lazy wrappers (file paths, memmap references, channel metadata), so the copy is cheap. Was the current by-reference behavior intentional?

This came up while thinking about adding time manipulation methods (like shift_times) to BaseSorting. If the sorting delegates to a shared recording, calling sorting.shift_times() would mutate the original recording as a side effect. With a copied recording, the sorting could safely manipulate its own time state without affecting anything external.

[h-mayorquin]

We (@alejoe91 @JoeZiminski @chrishalcrow) discussed this on 2026-04-16 in the maintenance meeting. Some notes:

The only use case we could identify for register_recording is to set the timestamps. In that sense, copying the full recording at registration might be overkill. For the sampling_frequency + t_start case we could just copy the time machinery. The problematic case is when the recording has an explicit time_vector that is a lazy reference (HDF5 dataset, zarr array), where copying could be expensive for long recordings.

For shift_times on sorting, one option we discussed was to consider timestamps on a registered recording as final and throw an error if someone tries to shift after registration.

After thinking about it more, I don't like this. I don't ike that whether shift_times works or raises an error depens on internal state (whether a recording is registered). When implementing shift_times on recording (#3509, #3117), @JoeZiminski and I dicussed that the internal representation of time should be invisible to the user. The same principle should apply here: whether a sorting has a registered recording or not should not change what methods are available.

I think there is a simpler approach that circumvents the shared-reference problem entirely. When shift_times is called on a sorting with a registered recording, we store the shift internally on the sorting (not on the recording). When resolving timestamps (e.g. converting spike frames to seconds), we first interpolate from the recording's time basis as we currently do and then apply the stored shift on top. The recording stays untouched. shift_times works the same way regardless of whether the sorting has a registered recording or not, no special cases, no leaking internals.

[chrishalcrow]

I think that sounds sensible @h-mayorquin. I'm a bit worried about users accidentally getting their recordings and sortings out of sync. Maybe we can add a "time support is equal" check in create_sorting_analyzer?