[kean]

Adds opt-in HDR: ImageRequest.dynamicRange applies gain maps with kCGImageSourceDecodeToHDR, and LazyImage.allowedDynamicRange(_:) also displays them. Standard requests decode as before. Thumbnails keep HDR; a request with processors stays standard, because they draw in 8 bits. See the new high-dynamic-range article.

Proof

• Brightest pixel through the real pipeline (1.0 = SDR white), Ultra HDR JPEG on Mac Catalyst (real UIKit and GPU): .standard 1.02 → .high 8.84, isHighDynamicRange true. macOS keeps it in 10 bits, also at 8.84.
• iOS 27 and tvOS 27 simulators can't apply a gain map, and Image I/O returns an all-zero image, so .high falls back to the SDR base (0.88). A 10-bit PQ HEIC reaches 4.17 there. Removing the guard fails gainMapIsApplied.
• preparingForDisplay() flattens a gain map (3.51 → 0.88), so HDR skips decompression. Removing that fails decompressionIsSkipped; the memory key, disk and processor rules are mutation-checked too.
• 20 new Nuke and 5 new NukeUI tests. macOS 1,783 + 638, iOS 27 1,831 + 648, tvOS 27 1,828 + 648: only ImagePipelinePreviewPolicyTests failed, under load, which it also does on main, and it passes alone. watchOS, visionOS, SPM and snippets compile.
• Default path: ImageRequest stays 112 bytes, a cache read is +7 instructions (+0.35%), a full load −0.65% against a control at −0.65%.
• Not run on a physical device, or compiled with Xcode 26.x (the local install is broken).