[web] Unify ui.Paint across CanvasKit and Skwasm - #196071

Flutter Web's two renderers each had their own copy of ui.Paint: CkPaint for CanvasKit and SkwasmPaint for Skwasm (which also drives Web Impeller). The two classes were about 85% identical (fields, defaults, setters, and a ~70-line toString), and they had started to drift apart. This PR replaces both with one shared implementation, following the same pattern already used for the unified Shader, ColorFilter, MaskFilter, ImageFilter and Vertices primitives:

• EnginePaint (new, primitives/paint.dart) is the single ui.Paint implementation for every renderer. It owns all Dart-side state, the defaults, toString, and the logic that used to differ between backends (the imageFilter getter, the blur-sigma guard, wrapping a ColorFilter used as an image filter). ui.Paint() now constructs an EnginePaint directly.
• BackendPaint (new, backend/paint.dart) is a minimal boundary with only dispose(). EnginePaint.createBackendPaint() gets one from Renderer.createPaint(EnginePaint, ...).
• CkPaint / SkwasmPaint are now thin per-draw BackendPaint wrappers. Each constructor reads an EnginePaint and builds the native paint the same way toSkPaint() / toRawPaint() did. They expose skiaObject / handle.
• All draw call sites (both canvases, saveLayer variants, drawAtlas, paragraph foreground/background paints, and the CanvasKit surface) move from toSkPaint() … delete() / toRawPaint() … paintDispose() to createBackendPaint() … dispose().

The native paint keeps its current per-draw lifecycle: it is created for one draw call and freed right after, and is never cached or registered with a finalizer. A cached native paint would go stale, because fragment shaders and image shaders replace their native shader without going through the Paint.

The PR also fixes a latent lifetime bug in EngineColorFilterImageFilter.getBackendFilter(). The native filter is cached in an Expando keyed on the ColorFilter, but its finalizer was attached to the short-lived wrapper. When a wrapper was garbage collected, the finalizer could free a native filter that the cache was still handing out. The finalizer is now attached to the ColorFilter, so it lives exactly as long as the cache entry.

This unblocks the Canvas unification, since every draw call takes a Paint.

Part of #175630

Behavioral Changes

• CanvasKit Paint.imageFilter getter now returns the filter that was set.
  • Before: (Paint()..imageFilter = someColorFilter).imageFilter returned an internal EngineColorFilterImageFilter wrapper.
  • After: it returns someColorFilter, matching Skwasm and native dart:ui.
• Skwasm blur mask filters with a zero, negative or non-finite sigma are now dropped in Dart before they reach native code, as CanvasKit already did. Skia could not create these filters anyway, so rendering is unchanged.
• Image filters built from a ColorFilter no longer risk having their native filter freed while it is still cached and in use (see above).
• On every renderer, ui.Paint() is now an EnginePaint. Assigning a value == to the current one to shader, colorFilter or imageFilter is a no-op, so the getter keeps returning the earlier, equal instance.

Where to focus

• lib/src/engine/primitives/paint.dart: the new shared state. Check the imageFilter setter, which caches the effective EngineImageFilter so repeated draws don't allocate a new ColorFilter wrapper each time, and effectiveMaskFilter, the shared sigma guard.
• lib/src/engine/canvaskit/painting.dart and lib/src/engine/skwasm/skwasm_impl/paint.dart: these constructors are meant to be line-for-line ports of the old toSkPaint() / toRawPaint(), including CanvasKit composing invertColors with the color filter and deleting the composed filter before the constructor returns, gradient dithering, and the null native-filter checks.
• Ownership invariant: every createBackendPaint() must be followed by dispose() in the same scope. The call sites in canvaskit/canvas.dart and skwasm_impl/canvas.dart are mechanical. New live-count tests check this for every paint-consuming Canvas method: Skwasm's native paintCount in test/skwasm/paint_lifecycle_test.dart, and an SkPaint constructor spy in test/canvaskit/painting_test.dart.
• lib/src/engine/primitives/image_filter.dart: a one-line finalizer target change, independent of the Paint refactor but surfaced by it.
• CanvasKit paragraph fallback paints (when only one of foreground/background is set) are now built from a default EnginePaint. They pick up EnginePaint's defaults, including anti-aliasing on, where a raw SkPaint had it off. Glyph anti-aliasing is controlled by the font, and no goldens changed.

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.