Add ability to customize the video redundancy timeout

[m-altaifi]

Summary

Adds redundancy.videos.timeout so a mirror of a large video can be given more time, as you retitled #5519 to ask for.

redundancy:
  videos:
    check_interval: '1 hour'
    timeout: '3 hours' # Maximum duration of a video mirror, mainly useful for big videos on slow connections

Why two things had to change

Mirroring was capped twice, and neither cap was configurable:

1. JOB_TTL['video-redundancy'] was hardcoded to 1000 * 3600 * 3. This is the cap the reporter hit: their job ran 12:11:46 to 15:11:46, exactly 3 hours, and failed with a bare Error: Timeout.
2. createStreamingPlaylistRedundancy passed VIDEO_IMPORT_TIMEOUT to downloadPlaylistSegments, which applies it as a single budget for the whole download rather than per segment. That value is 0.9 * import.videos.timeout, so the HLS mirror was governed by the video import setting: 1.8h at defaults, i.e. tighter than the job TTL.

So raising only one of them would not help, and an admin raising import.videos.timeout to make mirroring work would silently change video import behaviour too.

Both now derive from the new option, following the existing import.videos.timeout -> JOB_TTL['video-import'] -> VIDEO_IMPORT_TIMEOUT pattern:

'video-redundancy': CONFIG.REDUNDANCY.VIDEOS.TIMEOUT,
export const VIDEO_REDUNDANCY_TIMEOUT = Math.floor(JOB_TTL['video-redundancy'] * 0.9)

Effect at default config

	before	after
video-redundancy job TTL	3.00h, hardcoded	3.00h, from config
HLS download budget	1.80h, from import.videos.timeout	2.70h, from redundancy.videos.timeout
VIDEO_IMPORT_TIMEOUT	1.80h	1.80h, unchanged

The job TTL default is unchanged. The download budget now sits just under the job TTL instead of being controlled by an unrelated setting, so the download fails with HLS download timeout. rather than the job being cancelled first, and both scale together when the option is raised.

I picked '3 hours' to keep the job TTL exactly as it is today. That does loosen the effective download budget from 1.8h to 2.7h. '2 hours' would track today's real-world behaviour more closely but would shorten the job cap, so I went with the one that matches the intent of the issue. Happy to change it.

Verification

• pnpm run validate-config-schema — OK for config/default.yaml and the Docker production config
• config/config-schema.json regenerated with pnpm run generate-config-schema, not hand-edited
• tsc -b server/tsconfig.json — clean
• oxlint on the touched files — clean
• Checked at runtime that the values resolve through CONFIG into constants.ts (constants.ts reads CONFIG at module load, as it already does for video-import), producing the table above
• redundancy.videos.timeout registered in checker-before-init.ts alongside redundancy.videos.check_interval

I did not add an automated test: the behaviour is a multi-hour timeout, so a test would either not exercise it or need the constants stubbed. Happy to add one if you have a preferred shape.

Targeted develop since it adds a configuration option; happy to retarget to release/v8.3.x.

Closes #5519