fix(encode): pad odd dimensions so H.264 encode produces web-ready video

[Chouffe]

Problem

aris-encode --video-codec h264 silently fails on ARIS clips with odd
dimensions (e.g. 924×1765, a common sonar frame size). libx264 with
yuv420p requires even width and height, so ffmpeg fails to open the
encoder:

[libx264] height not divisible by 2 (924x1765)
Error while opening encoder
Nothing was written into output file — Conversion failed!

Worse, the failure was silent: encode_video_with_h264_codec caught the
ffmpeg.Error and returned normally, and the CLI exited 0 while leaving a
0-byte output file. A whole batch looked successful but produced empty files.

Discovered while converting a 107-clip ARIS selection (all 924×1765) for web
playback — every output was empty.

Fix

• Pad to even dimensions before libx264: pad=ceil(iw/2)*2:ceil(ih/2)*2
  (adds at most a 1px border, no rescaling). Even-sized inputs are unchanged.
• Web-ready flags: pix_fmt=yuv420p and movflags=+faststart for reliable
  in-browser playback (moov atom moved to the front for progressive streaming).
• Stop swallowing errors: re-raise ffmpeg.Error (the docstring already
  documents Raises: ffmpeg.Error) and fix the malformed error-log call.
• CLI exit code: aris-encode now counts failures and exits non-zero,
  mirroring aris-convert.

Test

Adds test_encodes_odd_dimension_video, which builds a real odd-dimension
(63×65) clip the way pyARIS does (MJPEG frames piped to mpeg4 — cv2.VideoWriter
silently rounds odd dims down to even) and asserts the output is non-empty with
even dimensions. This test fails on main and passes with the fix.

All 77 unit tests pass; ruff check and ruff format --check clean.