[FEATURE]: Let injected text parts opt into markdown rendering in the TUI #43318

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

A plugin or a tool that posts into a session through session.prompt has no way to get its text rendered. Everything sent that way becomes a text part on a user message, and the TUI renders user text through a plain <text> node while the assistant path renders through <markdown>:

packages/tui/src/routes/session/index.tsx
  1420  <text fg={theme.text}>{text()}</text>             // UserMessage
  1700  <markdown ... content={props.part.text.trim()} />  // TextPart, typed message: AssistantMessage

So a plugin that reports status back into the session shows raw markup on screen, sitting next to assistant output that is rendered. The case I hit is a background agent plugin posting its completion notice into the parent session: headings, bold and fenced code all arrive literally.

The only lever a plugin has today is synthetic: true, which hides the part from the message bubble. That is the right call for text meant only for the model, and it does not help when the text is also meant for the person watching.

Prior issues

#5675, #12791 and #21510 all asked for markdown in user messages and were closed. On #5675 a maintainer answered that plain user prompts are intentional, with the door left open. I read that as correct for typed prompts: rendering markdown over what someone typed would eat characters from their own words when they echo back. This request is narrower and does not touch that.

Proposal

Let a text part opt in with metadata.render set to "markdown", and render only those through the markdown component. Parts without the flag keep rendering as they do now.

TextPartInput already carries metadata, and resolvePart in packages/opencode/src/session/prompt.ts:992 spreads the input part into the stored part, so the flag already survives the round trip. The change fits inside the TUI with no schema or server work.

I have this working with tests and can open the PR. CONTRIBUTING asks for a design review before UI work, so I am raising it here first. If you would rather have a different key, a dedicated part type, or a separate surface for plugin status, tell me which and I will build that instead.