gamut-icc: encode H.273 transfer code points 4 and 5 (assumed display gamma 2.2 and 2.8) as parametricCurveType type 0

[justin13888]

PR #542 gives Trc::for_code_point seven encodable H.273 TransferCharacteristics values: 1, 6, 14, 15 (the BT.709 family), 8 (linear), 13 (sRGB) and 16 (PQ). Everything else is declined, so IccProfile::from_cicp returns None for it.

Two of the declined ones have an exact ICC closed form and are declined only because nobody wrote them:

H.273 code point	Table 3 entry	ICC.1:2022 §10.18 encoding
4	Assumed display gamma 2.2 — Rec. ITU-R BT.470-6 System M (historical)	function type 0, g = 2.2
5	Assumed display gamma 2.8 — Rec. ITU-R BT.470-6 System B, G (historical)	function type 0, g = 2.8

These are pure power functions, so they need no sampling and no new constants — the same Trc::Gamma(g) arm code point 8 already uses with g = 1.0. They appear in real signalling: SD material tagged from BT.470-6 carries 4 or 5, and an AVIF or HEIC nclx box can name either.

This is an additive capability, not a defect in #542: today those code points are refused rather than mis-encoded, which is the correct failure mode. The complement sweep added in #542 (no_unlisted_transfer_code_point_is_encodable) pins the current accepted set exactly, so adding 4 and 5 requires updating that list deliberately — which is the point of it.

Scope

• Two arms in Trc::for_code_point.
• The accepted-set list in the complement sweep.
• A differential test through lcms2-oracle that the written kTRC/rTRC evaluates to V^2.2 and V^2.8, in the shape of the existing oracle_gray_gamma_matches_lcms.
• Consider whether code point 7 (SMPTE ST 240, 4.0 × Lc toe, its own α/β) belongs in the same change; it is also a §10.18 type 3 closed form, but its constants are separate and it is far rarer.

Refs #424, #542.