Make `num_channels` available on `BaseRecordingSegment`

Currently BaseRecordingSegment has no concept of channel count. It knows its time dimension (sampling frequency, time vector, num_samples) but not its channel dimension. This forces segment subclasses to work around the limitation in various ways:

Passing num_channels from parent to segment at construction:

• BinaryRecordingSegment
• NoiseGeneratorRecordingSegment
• ZeroChannelPaddedRecordingSegment
• TracePaddedRecordingSegment

Inferring channel count from data shape:

• InjectTemplatesRecordingSegment infers from template array shape
• DriftingTemplatesRecordingSegment infers from template object

Fetching a sample just to get the shape:

• ResampleRecordingSegment._get_traces_gapped fetches 1 sample from the parent to determine output channel count (introduced in #4499)

The parent Recording always knows num_channels at the time it calls add_recording_segment. The proposal is to have BaseRecording.add_recording_segment() set num_channels on the segment automatically. This would:

• Give all segments a num_channels attribute for free, with the Recording as the single source of truth
• Eliminate the need for subclasses to store it independently
• Remove workarounds like 1-sample fetches to get channel count
• Make pre-allocation of output arrays straightforward without fetching data first

The change is small (a few lines in BaseRecordingSegment.__init__ and BaseRecording.add_recording_segment) and fully backwards compatible since existing subclasses that set num_channels themselves would continue to work.

Start with BaseRecordingSegment.init and BaseRecording.add_recording_segment, then review the listed segment implementations in binaryrecordingextractor.py, generate.py, zero_channel_pad.py, and drift_tools.py. Done means segments receive the parent Recording's channel count automatically and the existing channel-count workarounds can be addressed without changing the public behavior.