[web] Render bounded ImageFilter.blur on wimp - #196081

This PR passes the bounds of ui.ImageFilter.blur through to the web renderers, so wimp (the Impeller-based variant of skwasm) renders a real bounded blur.

ImageFilter.blur(bounds: ...) enables "bounded blur": samples from outside the rectangle are treated as transparent and the result is renormalized, so nothing outside the rectangle bleeds into the blur. That is what iOS-style frosted glass needs (ImageFilterConfig.blur(bounded: true)). The previous change made the web dart:ui filter keep bounds for ==, hashCode and its description, but the value still never reached a renderer. Impeller already implements bounded blur, and wimp already ships that shader, so this PR passes the value down:

• Renderer.createBlurImageFilter takes an optional ui.Rect? bounds, which EngineBlurImageFilter passes in.
• Skwasm converts bounds to a native rect (or passes nullptr), and the imageFilter_createBlur export takes a new nullable const DlRect* that it forwards to DlBlurImageFilter::Make(..., bounds). This is the same pattern canvas_saveLayer uses for its optional rect.
• Under skwasm-Skia, the same DisplayList filter goes through the shared dl_sk_conversions.cc, which ignores bounds. That matches native Skia without any web-specific code.
• CanvasKit accepts bounds and ignores it, because its JS bindings can't express a bounded blur. A TODO links to [Web] Implement bounded blur #175899.

Part of #175899

Behavioral Changes

• Wimp: ImageFilter.blur(..., bounds: r) now renders a bounded blur. bounds is in the canvas's local coordinate space, so it follows the current transform.
  • Before: the blur was unbounded, and content outside r bled in. With red to the left of r and blue inside it, the pixel 3px inside r read about [80, 0, 176, 255].
  • After: nothing bleeds in from outside r. The same pixel stays pure blue ([≤8, 0, ≥247, 255]).
• CanvasKit and skwasm-Skia: no change. They still render an unbounded blur, as native Skia does.
• All backends: unchanged for blurs without bounds, for zero-sigma blurs (still an identity filter), and for filterBounds.

Where to focus

• Primary review files: engine/src/flutter/skwasm/filters.cc, engine/src/flutter/lib/web_ui/lib/src/engine/skwasm/skwasm_impl/filters.dart and engine/src/flutter/lib/web_ui/test/ui/bounded_blur_test.dart.

• Nullable rect on the existing export rather than a new one: this keeps one call site and one binding, mirroring canvas_saveLayer. When bounds is null, the path is equivalent to before, because DlImageFilter::MakeBlur already forwarded to DlBlurImageFilter::Make with std::nullopt. Make copies the DlRect into a std::optional, so no pointer into the Dart stack scope outlives the call.

• Caching: bounds doesn't add a cache key. It is fixed for each EngineBlurImageFilter instance, and it is passed on every backend recreation, including the per-TileMode re-creation.

• Fallback is silent on purpose: CanvasKit and skwasm-Skia fall back without warning or throwing, matching native Skia. Apps that set bounded: true for an iOS look keep working everywhere.

• Tests: these are pixel-probe tests, not goldens. A red/blue split scene is blurred and one pixel just inside the bounds is read. A control test proves the probe can see bleed from an unbounded blur. The wimp-only tests cover:

  • no bleed
  • the canvas transform
  • ImageFilter.compose
  • reusing the filter after it backed a backdrop filter

  On the fallback backends, a test checks that the bounded blur matches the unbounded one. Zero-sigma and degenerate bounds are checked on all backends.

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.