fix(pptx/render): emit valid SVG <image> for image-fill backgrounds

[karthikmudunuri]

Problem

renderDeckToSvg rendered a slide's image-fill background as a CSS background shorthand dropped into an SVG fill="…" attribute:

<rect ... fill="center / cover no-repeat url("data:image/jpeg;base64,/9j/4AAQ…")"/>

That is not valid SVG — it's a non-paint value, and the nested unescaped quotes terminate the attribute. Browsers parse it leniently, but every strict SVG rasteriser (@resvg/resvg-js, librsvg, batik) rejects it:

SVG data parsing failed cause invalid attribute at 1:216 ... expected space not 'd'

This was the single blocker to a Chromium-free render path (parsePptx → renderDeckToSvg → resvg → PNG).

Root cause

The pptx importer stores image backgrounds as a CSS background shorthand (pptxToDeck.ts:3592: center / cover no-repeat url("…")). The renderer's image-ref detection (isImageRef) only inspected the start of the value (startsWith("data:image"), /^url\(/), so the shorthand wasn't recognised as an image and fell through to solidFrom, which returned the whole shorthand as a "named colour" → fill="…". renderBackground already had a correct <image> branch; it just never reached it.

Fix

• isImageRef now matches a url(...) anywhere in the value (gradients have no url(, so they're unaffected).
• imageHref extracts the URL from url(...) wherever it appears (data URLs use a )-free base64 alphabet, so non-greedy-to-first-) is safe).
• New imageFitPreserve: cover → xMidYMid slice, contain → xMidYMid meet, wired into renderBackground.
• Image-fill element fills now also yield valid SVG via solidFrom (which delegates to isImageRef), though only backgrounds use this form today.

Tests

Three new lock-in tests (9/9 green):

1. Image-fill background → real <image> with the data-URL xlink:href, preserveAspectRatio="xMidYMid slice", and no fill="…url(…".
2. contain background → preserveAspectRatio="xMidYMid meet".
3. Strict-parser lock-in: every rendered slide passes fast-xml-parser's XMLValidator (the non-browser equivalent of the resvg check), with an image-background slide as the regression case. Verified the validator rejects the old malformed output, so the guard is meaningful.

tsc --noEmit clean. Changeset: patch.

[karthikmudunuri]

Added a real-rasteriser guard on top of the XMLValidator well-formedness check.

@resvg/resvg-js is now a devDependency, and a new test drives an image-background slide through the package's default rasteriser path (no injected hook → the package's own dynamic @resvg/resvg-js import in defaultRasterize), end-to-end. It asserts a valid PNG signature and decodes the IHDR to confirm resvg produced a correctly-sized raster (1920×1080 capped at width 320 → 320×180), rather than just a non-empty buffer.

Confirmed resvg threw on the old fill="…url(data:…)…" output with the exact bug-report error (expected space not 'd'), so this is a true regression guard, not a no-op. All 10 render tests pass (environment: node, so the native addon loads).

[karthikmudunuri]

Reverted the resvg test + native devDependency (commit b6bca12). Keeping the package CI native-dep-free.

Rationale (agreed split):

Layer	Guard	Dependency
Package CI	XMLValidator (valid SVG / well-formedness)	pure JS — kept
Host (consumer)	resvg actually rasterises	already ships @resvg/resvg-js

This bug was an SVG validity regression (nested quotes / non-paint fill breaking attribute parsing) — exactly what fast-xml-parser's XMLValidator catches, with no native binary. That lock-in was confirmed to reject the old malformed output, so it's a real guard. The renderability round-trip belongs on the consumer side, where resvg already lives, and will be added there alongside the Chromium-free renderer.

Net diff is back to three files (changeset + XMLValidator test + renderDeck.ts fix); no pnpm-lock.yaml change. All 9 render tests pass. Good to merge as-is.