Remux encoding_tool tag hardcodes libx264 regardless of the input's real codec

[crippledgeek]

Surfaced during the whole-branch review of #618 (PR 2). Pre-existing, deliberately left out of scope there.

Problem

crates/rdlp-postprocess/src/pipeline/stages/recode.rs:490:

opts.video_codec.as_deref().unwrap_or("libx264")

On the remux fast path opts.video_codec is always None — remux copies the video stream rather than choosing an encoder. So the .unwrap_or fallback always fires, and every remux stamps the literal "libx264" into the encoding_tool metadata regardless of what the input actually contains.

Remuxing a VP9 file to MKV writes encoding_tool: "rdlp/<version> (libx264 + ...)" — claiming an encoder that never ran, for a codec that isn't there.

Why it wasn't fixed in #618

PR 2 fixed the audio half of the same tag (a video-only recode was stamping "+ copy" for audio it did not have, and a remux was doing the same). The video half is the same class of untruth but a different value and a different data path, so it was filed rather than folded in.

Fix shape

Thread the probed media_info.video_codec into the remux encoding_tool capture instead of the hardcoded fallback. The probe already runs on this path and the value is in hand.

Acceptance

• A remux stamps the input's actual video codec in encoding_tool, not libx264.
• A test pins the tag for a remux whose input codec is not h264 — it must fail against the current hardcoded fallback.
• The audio component's truthfulness (fixed in audio_encoder_registry catch-all resolves Mp3/Flac/Wav to AAC; knowledge lives in the wrong layer #618) is unaffected.

Refs #618