fix: mRAW/sRAW active-area crop uses wrong width for scale factor

[Kheil-Z]

Summary

• Fix CropDefault's scale-factor calculation using the wrong reference width for mRAW/sRAW files, which left part of the sensor's black border uncropped
• Only use active_area's width when Demosaic actually ran (and resized intermediate to match it); otherwise fall back to the raw image's full width

Why

CR2 files shot in Canon's mRAW mode render with a visible black border along the top/left edges in RapidRAW; the camera's own JPEG (same shot) has none. mRAW/sRAW files (cpp == 3) skip Demosaic entirely (already-RGB data), so intermediate is still at full raw resolution at the CropDefault step, but the scale factor was computed against active_area's width (the already-cropped rectangle), which only matches intermediate's resolution when Demosaic actually ran and resized it to that ROI. This produced an incorrect scale factor and under-cropped the border.

Validation

• Reproduced with a Canon EOS 80D mRAW CR2 file
• Camera's declared sensor border (SensorLeftBorder/SensorTopBorder Makernote tags, read via exiftool): left=36, top=18
• Before fix: visible black border remained after crop (~9px top / ~27px left)
• After fix: export log shows crop: Rect{36:18, ...} -- exact match to the camera's declared border, and the visible border is gone
• Tested end-to-end in a full RapidRAW build (not just the rawler crate) with this fork patched in via [patch], both headless CLI export and normal GUI export, JPEG and 16-bit TIFF output
• cargo check / cargo build --all-features / cargo check --all-features pass
• Full cargo test blocked by the same pre-existing, unrelated rawler/src/tiles.rs:334 SubPixel type-inference failure noted in other open PRs on this repo -- confirmed present on unmodified main as well