Function decoded_stream_data_with 

pub async fn decoded_stream_data_with<S: AsyncObjectSource>(
    src: S,
    s: &Stream,
) -> Result<Vec<u8>>

Fetches one stream’s bytes GUARANTEED DECODED — refusing the streams whose bytes decode_stream leaves encoded for the image layer. This is the fetch for every consumer that is not an image decoder: content streams, font programs, /ToUnicode CMaps, /CIDToGIDMap tables — anything that parses what it fetches.

This is AsyncObjectSource::stream_data with two refusals in front. A stream whose trailing /Filter entry is an image codec (DCTDecode, JPXDecode) fails with Error::UnsupportedFilter instead of handing back the passthrough (ISO 32000-1 7.4.9): a raw JPEG or JPEG 2000 codestream is indistinguishable from decoded data to anything that is not an image decoder, and a parser fed one chews binary garbage into operators, tables, or mappings with a clean result. And a /Filter that cannot be READ at all — a reference cycle, or a chain deeper than crate::source::MAX_RESOLVE_DEPTH — is refused with the resolve error, because a value that cannot be read might name an image codec, and decode_stream would leniently return the bytes as stored. Either refusal is the same reportable error as any other filter this library cannot run.

One leniency is kept, deliberately: a /Filter that READS as null (a dangling reference included — ISO 32000-1 7.3.10 makes one equivalent to null) or as an unusable value says “no filter”, which is exactly what decode_stream does with it; the stored bytes are the decoded bytes by that reading, and no codec name can hide in a value that is fully visible.

Raw AsyncObjectSource::stream_data remains correct in exactly one place: the image layer, which reads the trailing filter itself and decodes the passthrough. A new call site that is not decoding images belongs here instead. Same calling convention as page_content_with (src by value; see that function’s docs).