feat(core): expose Markdown tokenizer and inline renderer hooks

Use Case

OpenCode recently added Unicode LaTeX rendering through OpenTUI's fenced-code renderer API (opencode#45339). It works for latex and math fences, but models commonly emit $$...$$, \[...\], \(...\), and $...$ instead. Those forms do not reach the renderer.

We would like to support those delimiters without replacing OpenTUI's Markdown renderer or preprocessing Markdown into synthetic code fences.

Current Boundary

Checked against @opentui/[email protected] and the current upstream source:

• MarkdownOptions.renderNode lets an application override rendering of parsed blocks, but does not expose custom tokenization.
• parseMarkdownIncremental calls Lexer.lex internally with no caller-supplied lexer or extension options.
• renderInlineToken is a private path that emits text chunks, not a public inline equivalent of renderNode.

OpenCode's plugin API currently exposes only code-block renderer registration, so it would also need to expose any new upstream capabilities.

Requested Capability

Could OpenTUI expose per-renderable Markdown tokenization extensions and inline rendering hooks? The exact API is open for discussion. The goal is to let an application register custom block and inline syntax while OpenTUI continues to own Markdown parsing, layout, and incremental updates.

For the LaTeX use case:

• Display delimiters should produce a math block that can use the existing multiline Unicode renderer.
• Inline delimiters should support compact styled text within a paragraph. This does not require arbitrary multiline renderables embedded in a text line.
• Extensions should work consistently in paragraphs, lists, blockquotes, and table cells, including streaming and finalized content.
• The integration should preserve code spans and code blocks, delimiter escaping, surrounding styles, and links. Single-dollar currency detection can remain a policy of the math extension.
• Partial delimiters and unfinished formulas during streaming should not require the application to maintain a competing Markdown parser.
• Configuration should be scoped to the renderable rather than requiring global Marked mutations.

This is a request for generic extension points, not to move the LaTeX parser/layout engine into OpenTUI. The math engine and delimiter rules can remain in an application plugin.

• Not Actually Kit