fix(engine): pad odd output dimensions up to even for H.264/H.265 encode (#1802)

* fix(engine): pad odd output dimensions up to even for H.264/H.265 encode

A composition with an odd data-width or data-height (e.g. a custom 3:1
canvas at 1080x723) failed to encode to MP4. libx264/libx265 with 4:2:0
chroma subsampling (yuv420p, yuv420p10le) require both dimensions to be
even and abort before writing a packet:

  [libx264] height not divisible by 2 (1080x723)
  Error while opening encoder ... Invalid argument

Both the streaming encoder and the chunk encoder built the software
range-conversion filter ("scale=in_range=pc:out_range=tv") with no
even-dimension enforcement, so any odd-sized canvas reached libx264
unmodified and the whole render failed.

Add a shared withEvenDimensionPad helper that appends
pad=ceil(iw/2)*2:ceil(ih/2)*2 to the filter chain only for 4:2:0 pixel
formats. The pad rounds each odd dimension up by one pixel (a no-op when
already even) without scaling, so content is never resampled. Formats
that accept odd dimensions (ProRes 4444 yuva444p10le, VP9 yuva420p) are
excluded, so transparent/alpha output is untouched.

* fix(engine): extend even-dimension pad to GPU 4:2:0 encode paths

The odd-dimension pad added for libx264/libx265 only covered the software
encoder branches. nvenc, videotoolbox, qsv, and amf feed software frames
straight to the hardware encoder with no -vf chain, so an odd-sized 4:2:0
canvas on --gpu (or an auto-selected hardware encoder) reproduced the same
"height not divisible by 2" abort before any packet was written.

Add the even-dimension pad to the software-side -vf chain for those four
GPU paths in both the chunk and streaming encoders, reusing the shared
withEvenDimensionPad helper (the pad runs on CPU before the encode). vaapi
is left as-is: its existing format=nv12,hwupload conversion already aligns
odd dimensions before upload, so it is not double-padded. ProRes 4444 and
VP9 alpha stay untouched, exactly as the software fix excludes them.

nvenc/videotoolbox/qsv/amf arg construction is logic-tested (the pad filter
is asserted on the built arg list for 8-bit and 10-bit 4:2:0, with alpha
ProRes asserted padless); runtime hardware encode is not exercised here.

packages/engine/src/services/streamingEncoder.test.ts

@@ -309,6 +309,24 @@ describe("buildStreamingArgs", () => {
       expect(h265Args[h265Args.indexOf("-c:v") + 1]).toBe("hevc_amf");
       expect(h265Args[h265Args.indexOf("-qp_i") + 1]).toBe("23");
     });
+
+    // 4:2:0 HW encode aborts on odd dims just like libx264, and these paths
+    // feed software frames straight to the encoder with no `-vf`, so the
+    // even-dim pad (and only the pad, not the SW range scale) must be added.
+    it("pads odd dimensions (no range scale) for non-VAAPI GPU encoding", () => {
+      for (const gpu of ["nvenc", "videotoolbox", "qsv", "amf"] as const) {
+        const args = buildStreamingArgs(baseGpu, "/tmp/out.mp4", gpu);
+        const vfIdx = args.indexOf("-vf");
+        expect(args[vfIdx + 1]).toBe("pad=ceil(iw/2)*2:ceil(ih/2)*2");
+        expect(args[vfIdx + 1]).not.toContain("scale=in_range");
+      }
+    });
+
+    it("prepends range conversion to VAAPI chain (nv12 covers even-dim)", () => {
+      const args = buildStreamingArgs(baseGpu, "/tmp/out.mp4", "vaapi");
+      const vfIdx = args.indexOf("-vf");
+      expect(args[vfIdx + 1]).toBe("scale=in_range=pc:out_range=tv,format=nv12,hwupload");
+    });
   });
 });