feat(scrybe-tui): Mermaid / graphics in the terminal (kitty/iTerm2/WezTerm/sixel)

[hartsock]

Reuse the existing scrybe-mermaid PNG via a terminal graphics protocol (kitty / iTerm2 / WezTerm / sixel), with fallback to the fenced source. Part of #154 (re-scoped).

[hartsock]

Design sketch (wave close-out, 2026-07-22) — Mermaid/graphics in the terminal. The pieces exist: scrybe-mermaid-render produces PNGs (pure Rust, provenance-embedded) and scrybe-ratatui owns the fence rendering (now with the highlight feature precedent for optional heavy deps). Proposal: an optional graphics feature on scrybe-ratatui providing a protocol-detect + emit layer — Kitty graphics protocol and iTerm2 inline images first (both are just escape sequences wrapping base64 PNG — no new deps beyond base64), sixel later if demand (needs a quantizer dep). Detection: TERM/TERM_PROGRAM env + DA1 query with graceful fallback to today's ┌─ mermaid plain fence — never break dumb terminals. Composition problem to solve honestly: ratatui buffers CELLS, not pixels — inline images must be emitted OUTSIDE the ratatui draw (post-frame passthrough at a reserved cell region, the established ratatui-image approach — evaluate the ratatui-image crate before hand-rolling; it may satisfy the whole issue as an optional dep). Render pipeline: fence content → scrybe-mermaid-render::render_png (in-memory) → cache by content digest → emit. Sized: spike ratatui-image first (1 day), then either adopt or hand-roll the two protocols (medium). Suggest sequencing AFTER #166 (a live TUI is where diagrams pay off).