fix(diff): Count extra comp pixels when compare image is larger than base

[NicoHinderling]

Summary

• compareDifferentLayouts now counts extra comp columns (per row) and extra comp rows when the compare image is larger than the base — previously these pixels were silently ignored, causing false match: true for images where comp is wider or taller
• Use bounding box denominator max(base.width, comp.width) × max(base.height, comp.height) for diffPercentage so it stays ≤100%
• Add server test for different-dimension image detection
• Update existing layout diff test expectations to reflect the corrected pixel counts

Root cause

compareDifferentLayouts had asymmetric handling: it counted extra pixels when base > comp but completely ignored extra pixels when comp > base. For example, comparing a 200×200 base against a 300×200 compare image would ignore the 100 extra columns entirely, producing diff_count == 0.

This bug affects both CLI and server mode. The race condition from #169 (thread-safe allocator) is also theoretically present in CLI, but since the process exits immediately after one comparison, the overlapping memory never gets a chance to cause observable damage. In server mode, the corrupted allocations compound across requests. This dimension bug, however, is fully deterministic — it reproduces 100% of the time in both modes for any image pair where the compare image is larger than the base.

Why the diffPercentage denominator also changes

Counting extra comp pixels in diff_count without changing the denominator produces >100% percentages (e.g. 400% for a 4×4 base vs 8×8 compare). This would break downstream consumers that assume percentage is bounded at 100%.

For example, Argos (a major consumer of odiff) computes score = diffPercentage / 100 and stores it with a database constraint of maximum: 1. A >100% percentage would fail validation and crash. Argos itself avoids this by resizing images to matching dimensions before diffing, but other consumers may not.

The tradeoff: changing the denominator from base.width × base.height to max(base.width, comp.width) × max(base.height, comp.height) (the bounding box) means the percentage changes for different-dimension image pairs. For same-dimension images (the vast majority of real-world usage), the denominator is identical and behavior is unchanged.

Isolated test results (server mode, 100 runs × 11 pairs = 1100 comparisons)

Configuration	False matches	Rate
No fixes (baseline)	235/1100	21.4%
Dimension fix only (this PR without #169)	136/300	45.3%
ThreadSafeAllocator only (#169 without this PR)	100/1100	9.1%
Both fixes (#169 + this PR)	0/1100	0%

The 100/1100 remaining with ThreadSafeAllocator alone are all from width_change.png (200×200 vs 300×200) — the exact bug this PR fixes. The dimension fix alone does not help with the race condition (still 45.3% on a smaller test set).

Depends on

This PR depends on #169 (thread-safe allocator fix) and should be reviewed/merged after it.

Test plan

• zig build test-all passes (updated expectations for layout diff tests)
• CLI correctly reports 20000 different pixels for 200×200 vs 300×200 pair
• diffPercentage stays ≤100% — uses bounding box denominator
• Same-dimension images are completely unaffected (denominator unchanged)
• Consider whether the bounding box denominator is the right semantic choice for the project

[NicoHinderling]

Updated the test to use a new white8x4.png fixture (8×4 white image) paired against the existing white4x4.png (4×4 white). The overlap region is identical, so the only differences are the 16 extra comp pixels — this test fails without the fix (match: true) and passes with it (diffCount: 16).

[NicoHinderling]

(I can work around this in the short term but it involves me only running in CLI mode until this is merged, but for sure hope we can move back to server mode if this is merged!)