[jcwal1516]

Fixes #299 and #298, two CpuBatchDecoder failures on region requests (separate commits). First of a three-PR stack; the next two build on this branch.

Region tiles of large images failed with ImageTooLarge (#299)

Prepared region plans select only the region's code-blocks, but their sub-band and IDWT rectangles span whole resolution levels, so the CPU executors sized scratch for whole levels. 1024 px tiles of an 18000 × 12000 RGB image at full and half resolution asked for more than the 512 MiB cap.

• Preparation keeps the shared whole-level plan, which Metal and CUDA execute unchanged, and adds a CPU copy whose sub-bands and IDWT levels hold only what the region's stores read. The windows come from native region decode's IDWT window math (the same 16/40-sample margins RoiPlan uses), with each sub-band grown to the code-blocks it decodes.
• The CPU uses the copy only when it at least halves the plan's coefficients, or when the whole-level plan holds 16 Mi coefficients or more. The windowed IDWT is slower per sample than the banded whole-level one, so small-tile regions that cover most of a tile keep whole levels.
• The copy is built with fallible allocation; a failure is a preparation error, not a panic.

Four 1024 px tiles per level, default options, median ms (docs/benchmark-evidence.md has the command):

Input	Level	Before	After	Per-tile CPU
large-ht.j2c (HTJ2K)	0	ImageTooLarge	28	26
large-ht.j2c	1	ImageTooLarge	27	26
large-ht.j2c	2	48	24	22
large.jp2 (classic)	0	ImageTooLarge	152	149
large.jp2	1	ImageTooLarge	244	229
large.jp2	2	346	317	312
large-plt.jp2 (classic)	0	ImageTooLarge	136	133
large-plt.jp2	1	ImageTooLarge	224	220
large-plt.jp2	2	343	310	306

On 240 × 240 slide tiles (CMU-1-JP2K-33005), full requests are unchanged (9.8–10.0 ms) and region requests take 9.1–9.2 ms instead of 8.8–9.0 ms, 0.1 ms of it preparation. Without the half-the-coefficients rule they took 9.5–9.7 ms.

Reduced regions ending at a tile edge failed to prepare (#298)

Tile selection rounds tile bounds outward onto the reduced grid, so it can keep a boundary tile that contributes no samples. The referenced plan builders rejected a tile whose store copies nothing with "failed to decode code-block". They now leave it out, with its payload records, as single-image decode does. This affected the CPU and Metal batches alike.

On the 19 × 13 OpenJPH fixture in 11 × 7 tiles, 4,598 of the 17,290 half-scale regions failed to prepare; all now match single-image decode.

Testing

• Every region in the issues' reports decodes and matches single-image region decode.
• New tests: CPU batch region windows vs single-image decode for gray, RGB and RGBA, classic and HT, 5/3 and 9/7, 64 × 64 and 16 × 16 code-blocks, one tile and 128 × 96 tiles, eight regions × {region, half, quarter}; the windowed copy decodes exactly like the whole-level plan and nests its windows; whole-level geometry is kept for every backend; small images and near-full regions keep whole levels; every half-scale region of a tiled fixture prepares and decodes; regions ending at rounded tile edges for every OpenJPH fixture on the CPU, and for the 8-bit unsigned ones on Metal against the CPU.
• The test oracle now reads signed 8-bit native output one byte per sample instead of as 16-bit pairs.
• cargo test for j2k-types, j2k-native, j2k, j2k-ml; J2K_REQUIRE_METAL_RUNTIME=1 cargo test -p j2k-metal; cargo check -p j2k-cuda; cargo xtask fmt, clippy, clippy-strict, repo-lint, metal-compile, public-support, panic-surface, unsafe-audit; the quick Metal Clippy targets. CUDA execution was not run here (no CUDA host); its prepared geometry is unchanged, which a test pins.