Add bounded HTJ2K candidate rate control

[jcwal1516]

Summary

• Generate bounded consecutive HTJ2K cleanup, SigProp, and MagRef candidates with exact segment boundaries and per-pass distortion scores.
• Select candidates with a shared tile payload budget and preserve dependencies through packetization and quality layers.
• Add native Metal and CUDA candidate adapters, focused batch benchmarks, and exact scalar parity coverage.
• Add OpenHTJ2K and OpenJPH comparison support plus bounded row-decode reuse as supporting validation.
• Split the new candidate, diagnostics, benchmark, and tile-selection responsibilities into focused modules.

Validation

• cargo test -p j2k-types -p j2k-native -p j2k -p j2k-metal
• cargo test -p j2k-compare
• cargo test -p j2k-cuda-j2k-engine --all-features
• cargo test -p j2k-cuda --all-features --no-fail-fast
• python3 -m unittest discover -s scripts/tests -p test_open*j2k_reference.py
• cargo fmt --all -- --check
• cargo xtask repo-lint with 101 passing policy tests
• git diff --check and staged diff validation

Performance evidence

For verified resident 512 x 512 batches on the Apple Metal host, Metal beat parallel CPU packetization by 1.52x at batch 1, 1.94x at batch 4, and 2.99x at batch 16. The single-tile end-to-end lossy candidate path remains 2.65x to 2.81x slower than CPU, so this change makes no blanket Metal speed claim.

Known limits

• CUDA entropy writing remains serial within each code block; no CUDA throughput improvement is claimed.
• CUDA all-feature builds and availability-gated tests pass locally, but actual CUDA kernel execution was not possible on the aarch64 macOS host.
• Broader external Kakadu and OpenJPH encoder parity remains follow-up evidence.