Function check_color_context_consistency 

pub fn check_color_context_consistency<E, D>(
    enc: E,
    dec: D,
    img: &TestImage,
) -> Conformance
where
    E: EncoderConfig,
    D: DecoderConfig,
    <E::Job as EncodeJob>::Enc: Encoder<Error = E::Error>,
    <E::Job as EncodeJob>::AnimationFrameEnc: AnimationFrameEncoder,

Whatever [ColorContext] a decoder attaches to its output pixels is class-valid and the same on every decode path.

The decoded-buffer convention (zencodec docs/IMPLEMENTING.md, “Colour on the decoded buffer”): a decoder SHOULD attach SourceColor::to_color_context() to the buffers it emits, class-gated so an ICC only rides a layout its device class describes. This check enforces the two invariants that hold whether or not a codec has adopted the convention yet:

• Class-valid and non-empty — see the rules on the ICC device class in the module docs; an attached context must describe these pixels.
• Path equivalence — the one-shot buffer, every streaming strip (when streaming is advertised), and every animation frame on both the borrowed and the owned path (when animation is advertised) carry identical contexts. Strip and scratch buffers are rebuilt per batch and are where a context silently dies; a probe-era vs frame-era CICP divergence between paths shows up here too.

It does not require a context to be attached — a codec that attaches nothing passes (the pixels stay described by ImageInfo.source_color). Run check_color_context_attached for the strict positive direction once the codec has adopted the convention. Part of check_all.