Fix mediainfo failing on non-ascii filenames (empty child env + missing locale)

[ranke96]

Tested on master (1cd7e8f, server 1.7.5.1 / client 2.4.3), official Docker image on x86_64. My archive has hundreds of VODs with mostly Chinese filenames, which is how this surfaced.

Root cause (three things combine)

1. The Docker image sets no locale, so everything runs under the C/POSIX locale.
2. mediainfo v20.09 (Debian bullseye) cannot open files whose names contain non-ASCII characters under the C locale — it exits with code 1. With LANG=C.UTF-8 it works fine. Reproducible inside the image:

   dd if=/dev/urandom of="/tmp/測試 檔案.mp4" bs=1k count=10
   /usr/bin/mediainfo --Output=JSON "/tmp/測試 檔案.mp4"; echo $?              # exit 1
   LANG=C.UTF-8 /usr/bin/mediainfo --Output=JSON "/tmp/測試 檔案.mp4"; echo $?  # exit 0
   

3. Even if the image had a locale, it would never reach mediainfo: exec() in server/src/Helpers/Execute.ts spawned with env: env, and callers pass {} — the child got a completely empty environment (no PATH, no locale). startJob() likewise replaced the entire environment whenever a non-empty env was passed.

Impact

• Video metadata extraction failed for every VOD with a non-ASCII filename, forever. duration is derived from video_metadata, so every affected VOD showed "(Unknown)" duration in the UI.
• Because BaseVOD.toAPI() calls getDuration(true) and that falls through to getMediainfo() when metadata is missing, every /api/v0/channels request re-ran mediainfo for every affected VOD (each attempt also creates a Job, writes its pid file and broadcasts). With a few hundred VODs my dashboard took 26+ seconds TTFB on every single load, and the log accumulated 13,000+ Could not find duration lines.

Fix

• Execute.ts: spawn with env: { ...process.env, ...env } in both exec() and startJob(), so children inherit PATH/locale and custom vars overlay them.
• Dockerfile: ENV LANG=C.UTF-8 LC_ALL=C.UTF-8.

Verified locally: mediainfo now succeeds on Chinese filenames inside the container, and durations populate correctly.

Kept this PR minimal (just the env/locale fix). One possible follow-up: metadata repair currently happens inside toAPI() during list requests, so a file that keeps failing gets retried on every dashboard load — moving that backfill to a background task and serving only stored values from list requests would decouple page load time from individual broken files. Happy to open that as a separate PR/discussion if useful, didn't want to bundle it in here.