fix(site-builder): repair dead-code data:image clause in HTML block URI regex

Review follow-up on the Task 24 sanitiser widening (approved, no bypass
found). Two Important findings to close:

1. ALLOWED_URI_REGEXP's data:image/...;base64, arm sat inside the group
   that appends a trailing `:` to every alternative, so it required a
   second colon no real data URI has -- the clause could never match.
   Confirmed dead before the fix (poster/cite/href all stripped a valid
   base64 PNG data URI) and working after (all three now survive), while
   javascript:/data:text/html stay blocked. Pulled the arm out into its
   own top-level alternative.

2. Corrected an inaccurate comment/report claim that every allowed
   attribute value goes through this regex -- `src` on
   img/video/audio/source/image/track is additionally covered by
   DOMPurify's own DATA_URI_TAGS allow-list, which is mimetype-blind and
   bypasses the regex entirely (acceptable: none of those tags execute
   src as a document; iframe is correctly excluded from that list).

Adds two regression tests: the regex fix actually working, and the
DATA_URI_TAGS bypass pinned so a future DOMPurify change surfaces as a
failing test rather than a surprise. Fixture byte figures unchanged
(15,815 -> 14,899; fixture has no data:image URIs).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

craft/src/components/basic/HtmlBlock.tsx

@@ -41,11 +41,18 @@ const PURIFY_CONFIG = {
     // on*= handlers specifically to prove they still get neutralized/
     // dropped by staying outside the allow-list.
     'details','summary',
-    // Media (Task 24). All URL-bearing attributes on these (src, poster,
-    // srcset...) go through the same ALLOWED_URI_REGEXP gate as everything
-    // else -- see _isValidAttribute in dompurify, which URI-checks every
-    // allowed attribute value except a small fixed "inert" list (alt,
-    // class, id, style, title, ...) that never includes src/poster/srcset.
+    // Media (Task 24). URL-bearing attributes on these (poster, srcset,
+    // action, cite...) go through the ALLOWED_URI_REGEXP gate like
+    // everything else -- see _isValidAttribute in dompurify, which
+    // URI-checks every allowed attribute value except a small fixed
+    // "inert" list (alt, class, id, style, title, ...) that never includes
+    // src/poster/srcset. The one exception: `src` itself on img/video/
+    // audio/source/image/track is additionally covered by DOMPurify's own
+    // `DATA_URI_TAGS` allow-list, which accepts any data: URI on those
+    // tag/attribute pairs regardless of mimetype, bypassing this regex --
+    // see the ALLOWED_URI_REGEXP comment below and
+    // HtmlBlock.security.test.ts. Not a gap in the four non-negotiables:
+    // none of those tags execute their src as a document.
     'picture','source','video','audio','track','canvas',
     // Forms (Task 24). Site owner's explicit decision: allow the full
     // ordinary form surface. No on*= survives (FORBID_ATTR below), and
@@ -98,7 +105,20 @@ const PURIFY_CONFIG = {
     'stop-color','stop-opacity','gradientunits','gradienttransform',
     'preserveaspectratio',
   ],
-  ALLOWED_URI_REGEXP: /^(?:(?:https?|mailto|tel|data:image\/[a-z]+;base64,):|[^a-z]|[a-z+.-]+(?:[^a-z+.\-:]|$))/i,
+  // Review fix (Task 24 follow-up): the data:image arm used to sit inside
+  // the group that gets a trailing `:` appended for every alternative
+  // (`(?:https?|mailto|tel|data:image\/[a-z]+;base64,):`), so it required
+  // a SECOND colon after the one already in "base64,figure" -- no real
+  // data URI has that, so the clause could never match. It is now its own
+  // top-level alternative. NOTE: this regex is not the only thing gating
+  // data: URIs -- DOMPurify has its own internal `DATA_URI_TAGS` allow-list
+  // (img/video/audio/source/image/track) that accepts ANY data: URI on
+  // those tag/attribute pairs regardless of declared mimetype, bypassing
+  // this regex entirely. See HtmlBlock.security.test.ts for a regression
+  // test documenting that (acceptable: none of those tags execute their
+  // src as a document in mainstream browsers, and <iframe> -- which would
+  // be dangerous -- is correctly not in that DOMPurify list).
+  ALLOWED_URI_REGEXP: /^(?:(?:https?|mailto|tel):|data:image\/[a-z]+;base64,|[^a-z]|[a-z+.-]+(?:[^a-z+.\-:]|$))/i,
   // form/input/button/select/textarea removed from FORBID_TAGS (Task 24) --
   // they are now deliberately allowed above. style/script/object/embed/
   // link/meta stay forbidden; <style> in particular stays blocked even