feat(web): render fenced code as a container in the composer

[BarretoDiego]

Problem

Fenced code in the prompt composer was painted per line, so a block read as ragged highlighted runs rather than one surface, and the fence characters sat in the way of the text.

Fix

Promote a closed fence to a structural node (ComposerCodeBlockNode). The block becomes one container the caret types inside, and the fences stop being rendered while remaining part of the prompt — the node synthesizes them in getTextContent(), reusing the same collapsed-versus-expanded split the composer already has for mention and skill chips.

Inside a block the composer behaves like a code field:

• Typing ``` opens an empty block with the caret already inside.
• Enter breaks the line instead of sending.
• Tab indents two spaces, Shift+Tab outdents.
• Path and skill autocomplete stay quiet, where @ and $ are literal.

Every one of those has a way back out, so the caret can never be trapped: a second Enter on a blank last line, an arrow past either edge, or Backspace in an empty block.

A half-typed fence stays plain text and keeps the existing inline highlight — promoting it would move the caret out from under the user mid-keystroke. A pasted block is rebuilt from the prompt through the existing controlled update rather than by the typing path.

Notes

• composerCodeBlocks.ts is the single place that decides where a block starts and ends, so the node, the segmentation, and the syntax scanner cannot drift apart.
• Lexical joins sibling blocks with a double newline but a fence is separated by exactly one, so the composer now serializes the root itself.
• An empty block is written as ```\n```. That normalizes the one degenerate input where a block holding a single blank line is indistinguishable from an empty one; it collapses to empty rather than growing a line on every edit.

Verification

40 new tests plus the 182 existing composer tests, targeted lint, and tsgo --noEmit on apps/web — all green. The suites cover prompt round-tripping (text in → tree → identical text out), the collapsed/expanded cursor mapping across hidden fences, and fence detection.

Two real bugs the tests caught while building: the block's opening boundary resolved outside the fence, so typing at the start of a block would have inserted before it; and the empty-block ambiguity above, which grew a line per edit.

Interactive behaviour is not verified. The tests prove the data layer only. Enter, Tab, the auto-close, the caret landing inside the container, and how the container actually looks were never exercised in a browser — that is what this PR needs a human pass for. No before/after images for the same reason.

Written by Claude Opus 5 in T3 Code.

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 7610663.

This comment will update automatically after the next completed run.