fix(engine): accept libx264 preset names with NVENC and QSV (#442)

NVENC rejects the libx264 preset vocabulary (ultrafast / medium / slow /
...) with AVERROR(EINVAL) ("Error applying encoder options: Invalid
argument"), which surfaces as a bare `FFmpeg exited with code -22` from
spawn(). Because ENCODER_PRESETS passes these names straight through to
h264_nvenc / hevc_nvenc, every `--gpu` render using the `draft` tier
failed; `standard` (medium) and `high` (slow) only worked coincidentally
on ffmpeg builds that happened to accept those aliases. QSV has the same
problem on a narrower set (ultrafast / superfast / placebo).

Add `mapPresetForGpuEncoder` in utils/gpuEncoder.ts that translates the
libx264 vocabulary to each encoder's native names:

- nvenc: libx264 -> p1..p7 (already-native pN values pass through);
  unknown values fall back to p4 (medium)
- qsv:   ultrafast / superfast -> veryfast; placebo -> veryslow;
  everything else passes through
- videotoolbox / vaapi / null: unchanged

Both buildEncoderArgs (chunkEncoder.ts) and buildStreamingArgs
(streamingEncoder.ts) now route through the helper before pushing
`-preset` to the ffmpeg arg vector.

To make the next encoder-options failure diagnosable without re-running
ffmpeg by hand, \`formatFfmpegError\` in utils/runFfmpeg.ts now appends
the last 15 non-empty stderr lines to the error string. The four call
sites that previously swallowed stderr (encodeFramesFromDir,
muxVideoWithAudio, applyFaststart, and the streaming encoder exit
handler) have been updated.

Tested end-to-end on an RTX 4080 with ffmpeg 8.1 NVENC across
\`--quality draft|standard|high\` plus \`--video-bitrate\` and \`--crf\`
overrides; the 6 renders were visually equivalent to the CPU baseline.

Co-authored-by: roi32 <75878108+roi32@users.noreply.github.com>

packages/engine/src/utils/runFfmpeg.ts

@@ -22,6 +22,36 @@ export interface RunFfmpegResult {
 
 const DEFAULT_TIMEOUT = 300_000;
 
+const DEFAULT_STDERR_TAIL_LINES = 15;
+
+/**
+ * Build a user-facing error message for a failed ffmpeg invocation.
+ *
+ * Historically we reported only `FFmpeg exited with code N`, which is useless
+ * for diagnosing encoder-options failures — a rejected `-preset` surfaces as a
+ * bare `code -22` with no hint at which argument ffmpeg objected to. Including
+ * the tail of stderr turns those into a one-line signal (e.g.
+ * `Error applying encoder options: Invalid argument`) that tells the caller
+ * exactly which option to fix.
+ */
+export function formatFfmpegError(
+  exitCode: number | null,
+  stderr: string,
+  tailLines: number = DEFAULT_STDERR_TAIL_LINES,
+): string {
+  const tail = (stderr ?? "")
+    .split(/\r?\n/)
+    .filter((line) => line.length > 0)
+    .slice(-tailLines)
+    .join("\n");
+  if (exitCode === null) {
+    return tail ? `[FFmpeg] ${tail}` : "[FFmpeg] process error";
+  }
+  return tail
+    ? `FFmpeg exited with code ${exitCode}\nffmpeg stderr (tail):\n${tail}`
+    : `FFmpeg exited with code ${exitCode}`;
+}
+
 export async function runFfmpeg(args: string[], opts?: RunFfmpegOptions): Promise<RunFfmpegResult> {
   const startMs = Date.now();
   const signal = opts?.signal;