chat-adapters: DOM-returning render path + 4-adapter migration (#1100)

[RebelTechPro]

Summary

• Introduces the new adapter contract (renderMessageElement(): HTMLElement | null) on AbstractMessageAdapter + MessageAdapter interface — opt-in, falls back to the legacy renderMessage() + innerHTML path when an adapter hasn't migrated.
• Migrates all four shipping adapters: TextMessageAdapter, ImageMessageAdapter, URLCardAdapter, ToolOutputAdapter. Every chat content type that hits the live transcript now does so via DOM construction, not innerHTML. The TODO at the ChatWidget call site is removed.

Decisions made along the way

• Backward-compatible contract: new method is optional. Default returns null, call site falls back to the legacy string path. No big-bang migration — each adapter is its own commit / its own decision.
• Sub-renderer scope for ToolOutputAdapter: that adapter has 14 per-tool sub-renderers (Write/Read/Edit/Verify/Git/Search/Tree/Diff + 4 shell variants + Default). Migrating each one to return DOM nodes would have blown up the PR. Instead the scaffold is built via DOM and sub-renderer output is adopted via a detached <template>. Sub-renderers already escape user input through their internal escapeHtml() so the security boundary is preserved.
• Detached parser lifecycle: the parser templates (Text + Tool adapters) are lazily created on first use, not at module load — keeps these modules importable in non-browser contexts (tests, SSR, type-check).
• Side fix in ChatWidget: the no-adapter fallback was `<p>${message.content?.text}</p>` injected via innerHTML — small XSS hole for unknown content types. Replaced with a <p> + textContent.

Commit-by-commit

1. chat-adapters: add DOM-returning render path, migrate TextMessageAdapter — contract change on AbstractMessageAdapter + MessageAdapter interface. New protected helper createAdapterWrapper(). Text adapter overrides; markdown→tool-use→syntax-highlight→file-path-linkify pipeline unchanged, only the destination of the parsed HTML moves to a detached template.
2. chat-adapters: migrate ImageMessageAdapter to DOM-returning render — every interpolated attribute (img.src, img.alt, dataset.imageId, dataset.mediaId, dataset.url, dataset.filename) moves to property/dataset assignment. Caption (user-controlled) moves to .textContent. Action buttons gain aria-label mirroring title (same fix shape as the user-list a11y PR).
3. fix(chat): lazily create text adapter parser — moves the text adapter's parser from module-level to function-local so the module remains importable in non-browser contexts.
4. chat-adapters: migrate URLCardAdapter to DOM-returning render — concrete XSS fix: the string path interpolated ${additionalText} (user message text) directly into element-content position. Every interpolated value now travels via DOM property / dataset / textContent.
5. chat-adapters: migrate ToolOutputAdapter to DOM-returning render — scaffold via DOM, sub-renderer output via detached template, parser lazily created (consistent with the text adapter fix). data-tool-name / data-message-id via dataset, status icon via textContent, inline tool images via property assignment.

Why DOM over string

1. Assigning innerHTML on a live element destroys any Lit-managed reactive children — adapter renders blow away signal-bound state in sibling rows.
2. The XSS surface narrows: user-controlled text is destined for .textContent paths, not concatenated into HTML strings or attribute positions.
3. Performance: <template>.innerHTML parses once on a detached node, then cloneNode(true) produces a fragment to adopt — no live-tree re-parse.

Structural identity preserved

Every adapter migration preserves:

• All existing class names (selectors used by handleContentLoading(), updateCardWithMetadata(), CSS, and the event delegator)
• All data-action attributes (so MessageEventDelegator still finds its handlers)
• Static action handlers (handleCopy / handleOpenInTab / handleCardClick / etc.) read dataset.* via closest() — works unchanged

Test plan

• npm run build:ts → green (verified locally after each commit)
• Text-adapter visual parity — plain text, markdown (heading + list + code fence + inline code), stack trace (collapsible), file path (clickable), <tool_use> block.
• Image-adapter visual parity — single image, multiple images (grid), image with caption, image-load failure (error overlay + retry).
• URL-card visual parity — message with one URL + extra text, message with one URL alone, https / http (lock/unlock glyph).
• Tool-output visual parity — code/write, code/read, code/verify (pass/fail), git/commit, code/shell/execute (stdout/stderr/running). Each renderer's compact + expanded view.
• All data-action buttons still wire: open in fullscreen, download, retry, AI describe, copy tool output, open in tab, URL summarize, URL retry preview.
• No console errors during scroll-back over old messages.

⚠️ Not visually validated by me locally — TS compile is the only local check.

Out of scope (follow-ups, not blockers)

• Lint rule to prevent new innerHTML = on live transcript elements
• Refactoring ToolOutputAdapter sub-renderers to return DOM nodes directly (current path: scaffold via DOM, sub-renderer strings adopted via detached template)