fix(video): stop enlarging when both max dimensions are set

[rohanpoudel2]

The bug

imgvidcompress video clip.mp4 --max-width 4000 --max-height 4000   # source is 320x240

produced a 4000x3000 file. A 12x upscale, from two options the README documents as "Shrink to fit, never enlarge" — and from a function whose own docstring reads "Scale to fit inside the requested box without upscaling."

Cause

force_original_aspect_ratio=decrease fits the frame inside the box, but happily scales up to reach it. The single-dimension branches already guarded against that:

if (w !== undefined) return `scale=w=min(iw\,${w}):h=-2`;   // clamped
return `scale=w=-2:h=min(ih\,${h})`;                         // clamped

The both-dimensions branch took the box literally, with no clamp.

Separately, ResizeOptions.withoutEnlargement was honoured by the image path (src/codecs/image.ts:89) but never read anywhere in src/codecs/video.ts — silently ignored for video. It is now respected, defaulting to true to match images, so false is the way to opt into upscaling.

Scope

This is the CLI and library, not just the MCP server where it surfaced. Anyone passing both --max-width and --max-height to bound video output has been getting upscaled files.

Verified through the CLI

Case	Before	After
320x240, box 4000x4000	4000x3000	320x240
1920x1080, box 640x640	640x360	640x360
320x240, --max-width 4000 only	320x240	320x240

Tests

Two unit tests on the filter string, plus an end-to-end test that encodes a real file and reads the dimensions back with ffprobe. The existing coverage asserted only that the filter contained force_divisible_by=2 and never checked an actual output, which is why this survived.

Found while adversarially testing the MCP server (#16) against ffprobe rather than trusting the tool's own report.