Markdown Editor preview renders raw HTML as text because the SDK does not forward `allowHtml`

The Markdown Editor Preview pane renders raw HTML as text instead of rendering it. This was observed on bb 0.42.0 with plugin SDK 0.4.47 pinned; the newest published SDK, 0.4.88, also lacks an HTML option on MarkdownProps. The plugin passes the buffer to Markdown after only rewriting image URLs.

bb's own file preview already sets allowHtml:!0, but the plugin SDK's Markdown wrapper does not forward it. Passing allowHtml through a cast does not work because the wrapper explicitly constructs {content, className, linkRouting}. The host renderer supports the prop, so it looks like exposing and forwarding allowHtml on the SDK could be the whole bb-side fix. That is falsified if the renderer gates it on other context, or if bb declines to expose it for sanitization reasons.

This makes a file that renders correctly in bb's preview render incorrectly in the plugin. Inline HTML is the only way to get block markup inside a GFM table cell, including lists, line breaks, and nested markup. Converting an HTML subset to markdown as a pre-pass was considered and rejected: block HTML inside a GFM table cell has no markdown equivalent, so it does not fix the case that prompted this.

• Decide whether allowHtml should be opt-in for each call or implied for a file preview, and what sanitization applies when it is enabled.
• If bb declines to expose it, decide whether the plugin should own a remark/rehype pipeline and the resulting typography-parity and documentation tradeoffs. The Raw pane is out of scope.

Done is:

• A request to expose allowHtml (or equivalent) on the SDK's Markdown is filed with bb, or bb's answer is recorded here.
• Preview renders <ul>, <li>, <a>, and <code> written as raw HTML inside a table cell, matching bb's own markdown file preview for the same file.
• This is verified against a real file with HTML in a table cell, not only a fixture.
• If the plugin renders markdown itself, bb.description, the plugin README, and the root README table no longer claim it uses bb's own renderer.

Start at bb-plugin-markdown-editor/app.tsx, especially the Markdown call around line 384 and image URL rewriting around lines 225-238, then compare the SDK Markdown wrapper with bb's file preview using allowHtml. Determine whether the SDK or plugin should own HTML rendering and sanitization. Done means recording bb's decision or rendering HTML lists, links, and code inside a real GFM table cell and verifying it against bb's preview.