avif: reject color/alpha picture dimension mismatch instead of silent corruption

[scadastrangelove]

Fixes #3084.

AvifDecoder::read_image (both the 8-bit and 16-bit paths) composited the alpha plane into the output buffer with Iterator::zip, but the primary picture and the alpha picture are decoded independently — each via its own dav1d::Decoder, from its own coded data (AvifDecoder::new). Nothing checked that the two dav1d::Picture results actually had matching width/height before the zip.

Iterator::zip silently stops at the shorter of its two inputs, so a mismatch didn't error — it corrupted the composited image instead.

Verified against current main with a real dav1d-decoded crafted AVIF (color item 8x8, alpha item's own independently-encoded AV1 bitstream 4x4, re-muxed via avif-serialize):

• Pre-fix: read_image() returned Ok. Rows 0-3 correctly got alpha values from the 4x4 alpha picture, but rows 4-7 got stray alpha bytes not sourced from the visible alpha image at all — dav1d's picture-buffer padding beyond the coded height happened to satisfy the zip's row count. This is silent corruption, not simple truncation.
• Post-fix: the same file now returns Err("Format error decoding Avif: Alpha plane dimensions (4x4) do not match color plane dimensions (8x8)").

The original issue only flagged the 8-bit path; while fixing it I found the identical unchecked zip in the 16-bit path (process_16bit_picture) and fixed both.

Changes

• Add a dimension-equality check ahead of both zip loops (8-bit and 16-bit), returning a new AvifDecoderError::AlphaPlaneDimensionMismatch instead of silently compositing.
• Add a regression test (tests/avif_alpha_dimension_mismatch.rs) that crafts a real, dav1d-decodable dimension-mismatched AVIF at test time (via the crate's own ravif-backed encoder + mp4parse + avif-serialize, no external binary fixture needed) and asserts decoding now errors. Confirmed the test fails on unpatched main and passes with this fix.

Testing

Full suite (cargo test --features avif,avif-native,default-formats,rayon --lib --tests): all green except one pre-existing, unrelated failure in tests/limits.rs::avif (set_limits not enforcing width/height before dav1d decode) — reproduces on unmodified main too, already tracked as #3076.

Discovered by the rust-in-peace security pipeline.

[197g]

Looks like libavif also has an error code for this, so this is reasonable (with the clippy complaint fixed).