feat(android): render branded block icons with contrast-aware tinting

[jkmassel]

Stacks on top of #461 (native block inserter). Renders block icons via AndroidSVG, with contrast-aware tinting so branded icons read correctly against either a light or dark dialog surface.

This PR is two related slices that land together — splitting them would just be churn:

• Render SVG icons (commit 444c640) — adopts AndroidSVG (com.caverock:androidsvg-aar:1.4) and mirrors BlockIconCache on iOS. Handles three @wordpress/icons quirks the browser papers over with CSS: missing viewBox (e.g. core/site-tagline), root fill="none" (e.g. core/icon), and multi-fill branded icons that would flatten under a PorterDuff tint.
• Contrast-aware tinting (commit 69d4025) — addresses the "known limitation" called out in the first commit. Pipes icon.foreground through the JS bridge so single-colour brand icons (Pocket Casts red) render correctly, and adds a 3:1 WCAG contrast check so low-contrast brands (X #000000, Dailymotion #333436, WordPress Embed #0073AA) fall back to the theme tint instead of disappearing into the surface.

Screenshots

Pixel 9 Pro XL. The embed section is the interesting one — it exercises every branch of the tinting decision (monochrome, multi-colour branded, single-colour branded with good/bad contrast).

Embeds

Dark	Light

In dark mode, WordPress (#0073AA), X (#000000), and Dailymotion (#333436) fall back to the theme tint — all three fail the 3:1 contrast check against the chip surrogate. In light mode the same colours pass and render as-is. Pocket Casts / Reddit / Pinterest / Spotify / YouTube / Vimeo keep their brand colours in both modes (multi-colour or sufficient contrast).

Most used

Dark	Light

Bridge

getBlockIcon at src/utils/blocks.js:44 previously dropped icon.foreground — the JS metadata that the web editor applies as CSS color, which paths inside the SVG pick up via currentColor. Adds getBlockIconForeground and includes it in the serialised inserter payload, with matching iconForeground: String? fields on the Android BlockType data class and the iOS BlockType struct (iOS gets the field for parity; no rendering change).

Chip background

Wraps each icon in a 44dp RoundedRectangle chip filled with ~12% of the theme's primary text colour, mirroring the iOS BlockIconView treatment (Color(.label).mask over a secondarySystemFill chip). Without this, low-contrast brand icons rendered as near-invisible smudges on the dark bottom sheet.

Tinting decision

SvgIconCache.shouldTint decides per-icon whether to apply the theme tint:

1. No declared colours — pure monochrome; tint to text colour.
2. Multiple declared colours (Pocket Casts red+white, Animoto, Bluesky) — render as-is. A PorterDuff SRC_IN tint would flatten internal contrast into a silhouette.
3. Single declared colour — keep it if it has at least 3:1 contrast (WCAG 2.x SC 1.4.11 — minimum for UI graphics) against the surface the icon actually sits on; otherwise strip the brand colour and tint.

The contrast reference is the chip fill composited over the dialog surface, not the bare surface. Measuring against bare black makes marginal colours like WordPress blue (#0073AA) appear to pass at 3.16:1 while reading as dim against the actual ~#3B3B3D chip surrogate (2.1:1). resolveDialogSurface() looks up ?attr/colorSurface then ?android:attr/colorBackground so the surrogate matches what the user sees.

Test plan

• ./gradlew :Gutenberg:test detekt :Gutenberg:lintDebug :app:compileDebugKotlin — BUILD SUCCESSFUL
• Manually verified on Pixel 9 Pro XL with enableNativeBlockInserter on, dark theme: Pocket Casts renders red+white, Animoto/Bluesky render branded, X / Dailymotion / WordPress Embed render white (tint fallback), Site Tagline / Icon block still render correctly.
• Manually verified on Pixel 9 Pro XL, light theme: WordPress / X / Dailymotion render in brand colour (pass contrast against the light chip), branded multi-colour icons unchanged.
• Reviewer: verify iOS behaviour unchanged.

Related

• Builds on feat(android): add native block inserter #461