[jcwal1516]

Prepares JXR 0.4.0 on J2K 0.13.1, which is now on crates.io (v0.13.1 = 0c6b6e4).

Versions

Crate	crates.io	This PR	Why
jxr-math	0.1.1	0.2.0	CUDA Oxide removed the public CUDA_RECONSTRUCTION_CONSTANTS table (cargo semver-checks)
jxr-core	0.3.0	0.4.0	re-exports j2k_core::{BackendKind, BackendRequest, Rect} from J2K 0.13
jxr-native, jxr-metal, jxr-cuda, jxr, jxr-image	0.3.x	0.4.0	expose those types; jxr-cuda also has the CUDA Oxide kernels (#23)
jxr-mpsgraph	0.4.0	0.5.0	its public API takes jxr 0.4 types

The exact internal pins and both lockfiles follow. The J2K requirements stay 0.13.1 alongside J2K main (#25), not exact pins, so later J2K 0.13 patch releases resolve without a JXR release.

The lockfiles take J2K main 0c6b6e4, the commit tagged v0.13.1. docs/releasing.md gains a 0.4.0 section covering the J2K move, the CUDA Oxide kernels and the publish order. The README now names 0.4.0 as the current release.

Verification

• Locally, everything CI runs passes:
  • fmt;
  • all-feature Clippy with -D warnings;
  • all-feature workspace tests and jxr without default features;
  • docs with -D warnings;
  • fuzz fmt.
• cargo publish --workspace --dry-run --locked packages and verifies all eight crates in dependency order against crates.io's J2K 0.13.1.

After merge

1. Run the Metal and CUDA hardware workflows on the merged source.
2. Tag v0.4.0 and publish the eight crates in the order in docs/releasing.md.
3. Add the validation runs to the release notes.

wsi-rs follows JXR main with jxr = "0.3", so it needs jxr = "0.4" right after this merges, or its cargo latest CI step fails.