Window placement handling

[benedict-armstrong]

The current left_pad and right_pad are a bit complicated and error prone. This PR introduces a new more explicit way to set the window the model sees and adds a logging statement to avoid errors.

For example the following config:

data:
   windowing:
      kernel_length: 1.0       # length of window in seconds
      window_lead_min: -0.125  # leading edge location of the earliest possible window
      window_lead_max: 0.125   # leading edge location of the latest possible window

prints:

2026-06-01 22:04:45,596 - TimeDomainSupervisedAframeDataset - INFO - Window placement relative to merger (t=0):
  kernel=1.00s  sliding_range=0.25s  leading_edge=[-0.125s, +0.125s]

  |----------------------------------------------------|-----|
  [==============================================]              lead=-0.125s (earliest)
             [===============================================]  lead=+0.125s (latest)
                                                       ^ merger

For debugging and to avoid errors this is logged in the dataloader setup.

The change also allows pre merger windows like:

data:
    windowing:
      kernel_length: 1.0
      window_lead_min: -3.5
      window_lead_max: -3.0

which prints:

2026-06-01 20:38:46,487 - TimeDomainSupervisedAframeDataset - INFO - Window placement relative to merger (t=0):
  kernel=1.00s  sliding_range=0.50s  leading_edge=[-3.500s, -3.000s]

  |----------------------------------------------------------|
  [============]                                                lead=-3.500s (earliest)
        [============]                                          lead=-3.000s (latest)
                                                             ^ merger

This PR also updates the existing configs to work in this format. Possible extensions would be to add a logging statement for the location of the validation waveform views.

[wbenoit26]

Overall I quite like the idea of making it obvious where the window will be selected from. One thing I'm not clear on: does this enable new functionality, or is it just a re-parameterization that you find more intuitive?

[wbenoit26]

The line here needs to be updated so that the train config inherits the shared kernel length.

[wbenoit26]

Any particular reason for this width? I'd imagine you could double it without running into wrapping issues on most screen sizes.

[kyoon-mit]

addressed in fb03f5b (will start a new PR since this PR is directed to the wrong base branch and fork)

[deepchatterjeeligo]

The current left_pad and right_pad are a bit complicated and error prone.

@benedict-armstrong could you give an example what error you see? I personally find left_pad and right_pad pretty intuitive as opposed to leading_edge. So I have the same thought as @wbenoit26 in #448 (review).