chore(renderer): deprecate renderMarkdown prop and document actual markdown support

[LeslieOA]

Why

CanvasView declares a renderMarkdown?: (text: string, scheme: ColorScheme) => React.ReactElement prop that no code in the renderer consumes. Tracing it:

• CanvasView.tsx accepts the prop and passes it into the React context via CanvasProvider
• CanvasContext.tsx declares the type on the context value
• Nothing else in src/renderer/** reads it from context

The reason: TextNodeContent (which would have been the consumer) returns null intentionally — there's a comment explaining the choice was made to bypass a react-native-macos rendering limitation where native Text stops rendering beyond ~1500px from the parent View's origin. All text rendering goes through Skia (SkiaTextRenderer → paragraphBuilder).

So renderMarkdown is vestigial public API. Consumers (e.g. Workspace mobile) pass it in good faith but it has no effect.

What we actually render for text node bodies

Text nodes are parsed by paragraphBuilder.ts which uses the unified/remark ecosystem:

• remark-parse — CommonMark
• remark-gfm — strikethrough, tables, task lists
• remark-frontmatter — YAML (parsed as AST, used for Canvas Candy class extraction, not rendered)
• hast-util-from-html — inline HTML

Output is a flat list of styled segments rendered via Skia's text API. Supported inline marks: bold, italic, code, links (rendered as styled runs, not as tappable affordances). Supported blocks: headings, paragraphs, lists, code blocks, blockquotes, tables, task lists. Not supported: anything that requires a React component overlay (images embedded in markdown, custom code-block highlighters, callouts beyond what the extensions/callouts.ts layer recognises).

Done means

• renderMarkdown prop in CanvasView.tsx marked @deprecated with JSDoc explaining the situation and pointing at the actual markdown-rendering pathway
• Same @deprecated on the field in CanvasContext.tsx
• README's "What's inside" section gains a brief paragraph on what markdown rendering the renderer actually does (and what it doesn't)
• No behavioural change — the prop continues to be accepted (and ignored) so existing consumers don't break

Future

Whether to remove the prop entirely is a separate decision — a breaking change. Worth doing eventually, but not in this issue. Document and deprecate first; remove in a later major version.

[LeslieOA]

One per-platform fault line this deprecation should address explicitly in the docs, because it is where consumer confusion is most likely.

The renderer consumers inject into renderMarkdown in practice is @workspace.sh/react-native-markdown (workspace-sh/markdown), and that library is Apple-only today — its Rust core ships as an xcframework for iOS/macOS, with the Android implementation tracked in workspace-sh/markdown#132. The net effect on Android is that canvas text nodes fall back to plain text rather than rich markdown.

So whatever shape the deprecation takes (JSDoc @deprecated, README paragraph, eventual removal), the documentation should state per-platform behaviour explicitly rather than describing markdown support in platform-neutral terms:

• iOS / macOS — rich markdown rendering
• Android — plain text, until workspace-sh/markdown#132 lands

Without that line, a consumer reading "markdown is supported" will reasonably expect parity on Android and file the resulting gap as a bug against this repo, when the actual tracking issue lives upstream. Pointing at workspace-sh/markdown#132 from the deprecation notes gives them somewhere correct to subscribe.