feat(tui): plugin API to format delimited blocks in user messages - #55442

Note: I'm aware v1 is now the maintenance branch and new features go to v2 only. This PR is here for others to use, and I'll submit the v2 version once I've migrated my whole plugin system to it.

Issue for this PR

Closes #55440

Builds on #55441 (markdown in user messages), which builds on #54968 and #54704; their commits come first here. Review only the last commit.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Tools and plugins that prompt on a user's behalf wrap metadata in delimited blocks ([vibeterm_metadata] ... [/vibeterm_metadata]). In the transcript that block is indistinguishable from what the person typed. This adds a way for a plugin, or the user's config, to say how such a block is drawn.

• api.blocks.register({ open, close, format }) on the TUI plugin API, scoped to the plugin like its other registrations, and syntax.blocks in tui.json, which is tried first.
• A block runs from a line that is exactly open to the next line that is exactly close, surrounding spaces aside. In open, * matches a run of non-space characters, and each * in close stands for what it matched, so [tool_*] ... [/tool_*] covers a family of blocks and closes each at its own name. An opening line with no closing line stays ordinary text (messageSegments in util/message-blocks.ts).
• format: "yaml" colors key: value lines: keys, values by type (strings, numbers, booleans, null), # comments and the delimiter lines muted. Any other format is a language id colored by its grammar (json, sql, ...).
• Only colors change: the chunks cover the text exactly, so a block reads and wraps as written, and it never draws in red. Blocks are drawn whether or not syntax.user_messages is on.
• It applies to user messages. Assistant text goes through the <markdown> renderable, which has no per-range hook; extending it there would mean a markdown-level extension, so I left it out.

If the tool input block (#54707) lands, its key/value colors and yamlColors are the same palette and can become one function; my fork has them merged that way.

Bigger picture, and the part I'd most like feedback on: this is a narrow first step toward plugin-defined renderers for message content. A plugin can already add routes and slots; it cannot say how a span of message text is drawn. A small "content formatter" registry (match a span, return colors or a component) would let plugins format their own protocol blocks, tool-specific markers or structured attachments without each one patching the session view. Happy to reshape this toward whatever API you'd prefer.

How did you verify your code works?

• bun typecheck in packages/tui, packages/plugin and packages/opencode; the full packages/tui suite passes. message-blocks.test.ts covers matching by name, a mismatched closing tag inside a block, unclosed blocks, rule order and exact coverage of the text; yamlSegments keeps every character and kinds values by type; user-text.test.tsx compares plain and colored frames with a YAML block at 40, 80 and 160 columns.
• A real TUI at 80 and 160 columns, once with the rule in syntax.blocks and once registered by a TUI plugin through api.blocks.register: keys, strings, numbers and booleans are colored, the delimiter lines muted, and the screen text is byte-identical to the rule being absent.

Screenshots / recordings

┃  [vibeterm_metadata]              <- muted
┃  call: vibeterm_spawn_session     <- key / string colors
┃  process_id: 2597181              <- number color
┃  enabled: true                    <- boolean color
┃  [/vibeterm_metadata]             <- muted

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

This PR is AI generated, but under direct supervision and on request of @Nowaker.