preprocessing not taking into consideration that audio trimming might make it fit into max_audio_length

### Bug description

When running preprocessing, if the original audio file is longer the the `max_audio_length` defined in `config/everyvoice-shared-data.yaml` it will be skipped without any trimming happening where it might actually fit into the `max_audio_length` afterwards once the trimming was actually done.

Example file I created with long silence start and end ( raw)

```
$ soxi test_ok_long_good.wav

Input File : 'test_ok_long_good.wav'
Channels : 1
Sample Rate : 44100
Precision : 16-bit
Duration : 00:00:21.90 = 965632 samples = 1642.23 CDDA sectors
File Size : 1.93M
Bit Rate : 706k
Sample Encoding: 16-bit Signed Integer PCM
```

After silence remove start & end & throughout the audio file is ~ 15 secs using preprocessing...
```
soxi test_ok--LJ--eng--audio-22050.wav

Input File : 'test_ok--LJ--eng--audio-22050.wav'
Channels : 1
Sample Rate : 22050
Precision : 16-bit
Duration : 00:00:14.51 = 320000 samples ~ 1088.44 CDDA sectors
File Size : 640k
Bit Rate : 353k
Sample Encoding: 16-bit Signed Integer PCM
```

If I set` config/everyvoice-shared-data.yaml` --> `max_audio_length: 16.0 ` Even after prunning it should be under the set defined max_audio_length , it will be still skipped and not processed.

```
Partial report showing only audio statistics:
type quantity
-------------------------- ----------
processed files 299
previously processed files 0
missing files 0
audio_empty 0
audio_too_short 0
audio_too_long 1
duration 0h 32m 23s
╭───────────────────────────── Congratulations 🎉 ─────────────────────────────╮
│ You've finished preprocessing: audio, spec, attn, text, pitch, energy. Your │
│ files are located at │
│ /gpfs/fs5/nrc/nrc-fs1/ict/others/u/tes001/TxT2SPEECH/LJ_TEST_compare/300_all │
│ /preprocessed. Here is a report: │
│ type quantity │
│ -------------------------- ---------- │
│ processed files 299 │
│ previously processed files 0 │
│ missing files 0 │
│ missing symbols 0 │
│ skipped processes 0 │
│ nans 0 │
│ audio_empty 0 │
│ audio_too_short 0 │
│ audio_too_long 1 │
│ duration 0h 32m 23s │
╰─ Next Steps Documentation: https://docs.everyvoice.ca/stable/guides/custom/ ─╯
```

Also, the preprocessing report should be reflecting this . For example. the initial partial report should reflect the "raw" unprocessed data with one listed as audio_too_long where the second part after Congratulation if the preprocessing was actually done, it should now say `audio_too_long 0 ` since the trimming did it's job...

### How to reproduce the bug

Need to created a test audio file or use the attached example...

[test_ok_long_good.wav.txt](https://github.com/user-attachments/files/21669182/test_ok_long_good.wav.txt) ( Rename the attached file to .wav )

### Error messages and logs

See output log file, no error messsages.

### Environment

Latest version

### More info

_No response_

Start with the preprocessing flow that reads max_audio_length from config/everyvoice-shared-data.yaml and processes the attached test_ok_long_good.wav example after renaming it to .wav. Check where the original duration is rejected and where the partial and final reports count audio_too_long. Done means eligible audio is trimmed before the length decision and the final report reflects the post-trimming result.

Written by the indexing model from the issue text.