[web] Respect Uint8List view bounds when detecting animated WebP/GIF - #196010

detectImageType in the web engine sniffs WebP and GIF headers to decide whether an image is animated. The WebP and GIF header readers were given data.buffer.asByteData(), a view of the whole backing buffer starting at byte 0, rather than a view of the Uint8List itself. When the image bytes are a view into a larger buffer (for example Uint8List.sublistView, an image embedded in a container format, or a slice of a pooled network buffer), the readers looked at whatever came before the image in the buffer instead of the image's own header. Animated WebP and GIF images in such views were misclassified as static and sent down the single-frame decode path, so they did not animate. A static image stored right after an animated image in the same buffer could also be misreported as animated.

This change builds both readers from ByteData.sublistView(data), which covers exactly the bytes of data (respecting offsetInBytes and lengthInBytes) without copying. The signature check and AVIF detection already index data directly and were unaffected.

Related: #151911 (animated WebP/GIF detection in detectImageType). No separate issue was filed for this bug.

Behavioral Changes

• Before: detectImageType(view) on an animated WebP/GIF stored at a non-zero offsetInBytes in its buffer returned ImageType.webp / ImageType.gif (static), so the image decoded as a single frame.
  After: it returns ImageType.animatedWebp / ImageType.animatedGif, the same result as for a standalone copy of the same bytes.
• Before: a static WebP/GIF stored after an animated image in the same buffer could be classified as animated (the readers parsed the earlier image).
  After: it is classified as ImageType.webp / ImageType.gif.
• Before: on a truncated WebP/GIF view, the readers could read past the end of the view into unrelated bytes of the backing buffer.
  After: reads are bounded by the view, so a truncated view behaves like a truncated standalone buffer (which already throws a RangeError today; hardening that is left to a separate change).

Where to focus

• Primary file: engine/src/flutter/lib/web_ui/lib/src/engine/image_format_detector.dart, the two reader call sites in detectImageType. The readers themselves are unchanged; they start at position 0, so handing them a view based at offsetInBytes is the whole fix.
• Why ByteData.sublistView instead of copying: it's a zero-copy view on both dart2js (DataView(buffer, offset, length)) and dart2wasm, so detection cost is unchanged. The readers only use getUint8, so unaligned offsets are fine.
• Tests: engine/src/flutter/lib/web_ui/test/engine/image_format_detector_test.dart. A table of fixtures (animated/static WebP, animated/static GIF, AVIF) runs against several buffer layouts: leading padding only, trailing padding only, both, and an unaligned offset. The padding bytes are 0xFF, so they can't accidentally match a header. The "static image stored right after an animated image" cases cover the opposite failure, where the old code returned animated for a static image.
• Out of scope: making the readers tolerate truncated or malformed streams. That is a pre-existing issue for all inputs, not just views.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.