feat(gainmap): ISO 21496-1 URN + PRIMARY_APP2_BODY + JpegApp2BodyWithUrn/JxlJhgm

[lilith]

Summary

Promotes the ISO 21496-1 namespace URN and the primary-image signal marker
into zencodec::gainmap, and restructures Iso21496Format so each variant
names the container that consumes exactly those bytes.

New format variants

Variant	Discriminant	Bytes	Canonical consumer
JpegApp2 (deprecated)	0	same as JxlJhgm	historical alias
AvifTmap	1	version(u8=0) + <JxlJhgm>	AVIF tmap item payload
JxlJhgm	2	min_ver + writer_ver + flags + channel data	JXL jhgm bundle gain_map_metadata field
JpegApp2BodyWithUrn	3	URN(28) + <JxlJhgm>	body of a JPEG APP2 segment (after FF E2 + u16 BE length)

The Body qualifier on JpegApp2BodyWithUrn signals explicitly that the
FF E2 marker and u16 BE length envelope are NOT included — those stay
with zenjpeg as pure JPEG syntax.

Discriminants are pinned with explicit = 0..3 values plus a const _: () = assert!(...)
block so future variant changes trip at compile time instead of silently
shifting as u8 results.

Deprecation

• Iso21496Format::JpegApp2 → misleading (bytes lack the URN). Deprecated
  alias for JxlJhgm, kept at discriminant 0 so as u8 casts keep working.

Public constants at zencodec::gainmap:: (re-exported at the crate root)

• ISO_21496_1_URN: &[u8; 28] — the urn:iso:std:iso:ts:21496:-1\0 namespace
  string. Byte-identical to libultrahdr's kIsoNameSpace.
• ISO_21496_1_PRIMARY_APP2_BODY: &[u8; 32] — the full JPEG APP2 body
  (URN + min_version=0 + writer_version=0) that the primary image of a
  canonical Ultra HDR JPEG carries. Callers memcmp against this to emit or
  detect; no need to concatenate URN + version bytes themselves.

GainMapParseError::UrnMismatch added for URN-aware parsing failures.

Agent survey of codec needs

Before settling on the single 32-byte PRIMARY_APP2_BODY constant vs. a
4-byte VERSION_SIGNAL + helper function, I had agents audit zenjpeg,
zenavif, and zenjxl. Result:

Codec	Needs signal?	Reads version fields separately?
zenjpeg	Yes (primary APP2 emit/detect)	No — discards writer_version, delegates min_version check to parse_iso21496_fmt
zenavif	No	No — uses ISOBMFF iref/dimg for signaling; version bytes are always bundled in the tmap payload
zenjxl	No	No — gain_map_metadata is an opaque round-trip blob

One codec memcmps the full APP2 body; zero codecs extract version fields in
isolation. The 32-byte constant is what callers actually need.

Single-allocation serialization

Extracted serialized_size(params, format) plus *_into(params, &mut Vec<u8>)
appenders so each public path does exactly one allocation. JpegApp2BodyWithUrn
shares the same buffer as its payload — no intermediate Vec.

Why this and not the full JPEG APP2 marker (FF E2 + length)

That envelope is pure JPEG syntax and belongs in zenjpeg; only the URN/payload
pieces are ISO-defined and cross-codec. This PR is intentionally scoped to
zencodec; a follow-up will DRY up zenjpeg's three copies of the
push 0xFF; push 0xE_; push length_hi; push length_lo; pattern in its
XMP / MPF / ISO APP2 writers and rewire the ISO writers to consume
Iso21496Format::JpegApp2BodyWithUrn and ISO_21496_1_PRIMARY_APP2_BODY
from zencodec directly.

Test plan

• cargo test --all-targets (423 + 100 + 29 + 0 pass)
• cargo test --doc (13 pass)
• cargo clippy --all-targets -- -D warnings (clean)
• cargo semver-checks check-release (clean — discriminants pinned and preserved, deprecated variant kept as alias, new variants appended; enum is #[non_exhaustive])
• cargo build --target wasm32-wasip1 --lib (no_std clean)
• New tests: URN shape, primary APP2 body shape, primary body not parseable as full metadata, roundtrip JpegApp2BodyWithUrn, URN-mismatch / wrong-URN / short-input rejection, deprecated JpegApp2 alias equivalence, discriminants pinned to explicit values