fix(sanitize): allow trusted-host iframe embeds in post/page body content

[asachs01]

Summary

base.outlet's html prop (the markdown-rendered post/page body) is typed richtext, so escapeProps() sanitizes it through RICHTEXT_CONFIG — an allowlist built for short marketing copy with no img/video/table/iframe. marked passes raw HTML blocks through untouched during markdown parsing, so a pasted YouTube <iframe> (or any other embed) survives parsing and then gets silently stripped at the later sanitize step — with no error or warning surfaced to the author.

Confirmed there's no existing zero-code path around this: the Tiptap post-body editor has no video/embed insertion feature ("Add Media" opens the media-library file picker, not a URL-embed), and base.video (the module that could otherwise host a YouTube embed) is page-builder-canvas-only — it has no bridge into markdown post-body fields.

Change

• New richtextBody control type, distinct from richtext, used only by base.outlet.
• New POST_BODY_CONFIG DOMPurify config: allows img/video/table/iframe, with iframe scoped to a trusted-host allowlist (youtube.com, youtube-nocookie.com, subdomain-aware) via an uponSanitizeElement hook.
• Lookalike-host tests included (youtube.com.evil.com, evilyoutube.com both correctly rejected) to guard the allowlist logic itself.
• Every other richtext-typed field (short-copy fields elsewhere in the module system) is unaffected — this only changes the config used by base.outlet's body prop.

Test plan

• Full suite green (6611+ tests passing at the time this was built, no regressions)
• tsc clean
• eslint clean
• Manually verified against a real broken post in a live deployment: iframe embed survives the write path (confirmed via API), was stripped at render time before this fix, renders correctly after.

Happy to adjust the trusted-host list or expose it as a config option if that's preferred upstream — went with a hardcoded YouTube-only allowlist since that's the immediate need, but a configurable allowlist would be a small follow-up if there's appetite for embeds from other providers.

[jozef-simo]

Tried this against a Webflow migration where the post bodies are HTML, and POST_BODY_CONFIG fixes the images — but video embeds still lose their source.

The config allows video but not source or poster, so the common form:

<video controls poster="/uploads/thumb.avif">
  <source src="/uploads/clip.mp4" type="video/mp4">
</video>

publishes as a bare <video controls> — no poster, no <source>, nothing to play. Only <video src=…> survives, and that isn't what most editors and importers emit.

Suggest adding source to ALLOWED_TAGS, and poster, type, playsinline, loop, muted, preload to ALLOWED_ATTR. figure/figcaption are worth considering too — they're what rich-text editors wrap images in.

Separately, and maybe worth a line in this PR's description: with the current narrow RICHTEXT_CONFIG, DOMPurify's element traversal on happy-dom skips the node after each removal, so exactly one <img> per document is dropped and the rest survive. That's why today's behaviour reads as an odd rendering glitch — one missing picture per post — rather than "images aren't allowed in bodies at all". Once this PR widens the allowlist the symptom disappears, but anyone bisecting the old behaviour will find it puzzling.

Context: found while doing an AI-assisted migration of a ~26-post site from Webflow into Instatic, so the findings come from that codebase rather than a hand-written repro.