Add high-throughput J2K/HTJ2K batch decoding

[jcwal1516]

Summary

• add prepared, homogeneous batch decoding for J2K, JP2, and HTJ2K inputs
• retain reusable CPU, CUDA, and Metal decoder sessions and allocation caches
• expose resident and external-destination GPU output paths with indexed metadata/errors
• keep j2k-ml as a thin Burn allocation and device-interop adapter
• fix stacked multi-tile output, Metal queue ordering, and decoded-pixel round trips
• use distinct-input benchmark workloads and preserve repeated-input mode as a labeled diagnostic
• split oversized codec and repository-policy modules along existing ownership boundaries

Why

Medical training pipelines need high-throughput Gray/RGB integer decoding without routing decoded GPU pixels through host memory. HTJ2K is the primary optimized path while classic JPEG 2000 remains covered.

Validation

• formatting, affected Clippy checks, and strict repository lint
• CPU release and public-support gates
• stable API and semver gates
• complete Metal release suite
• focused CUDA benchmark probe and complete CUDA release suite on the NVIDIA WSL runner
• complete distinct-input Metal matrix: 768 codec-resident rows and 768 Burn rows
• separate labeled repeated-input Metal diagnostic

Performance status

Full grayscale passes the staged comparison on the M4 Pro: 1.431x geometric-mean speedup at batch 1 and 2.338x at batch 8. Larger color batches accelerate, but RGB/RGBA batch 1 and 8 remain slower than staged CPU decode/upload. Those rows stay explicitly selectable and are not presented as universally accelerated.