feat(cli): render assistant output as markdown

[doahc]

What changed

• render final Hermes CLI assistant responses with Rich Markdown inside the existing response panel
• keep a plain-text fallback if markdown rendering fails
• disable OSC 8 hyperlinks in terminal output so prompt_toolkit does not show raw escape sequences
• add focused CLI tests for markdown rendering and chat-path integration

Why

Hermes CLI responses were displayed as plain text even when the model returned Markdown. This makes headings, emphasis, lists, and fenced code blocks much harder to read. Rich Markdown gives the CLI a clearer final-response surface without changing the agent loop.

How to test

1. Run source venv/bin/activate && pytest tests/test_cli_markdown.py tests/test_cli_init.py -q
2. Start hermes
3. Ask for markdown with headings, italics, bold text, links, and a fenced code block
4. Verify the final response renders formatted in the CLI panel and links show readable text instead of raw OSC 8 escape codes

Platforms tested

• Linux
• Interactive CLI
• Telegram gateway path (manual restart + live check)

[teknium1]

Thanks for the PR @doahc — markdown rendering in the CLI is definitely something we want. However, we're going to close this one for now because of a fundamental compatibility issue.

Our CLI runs inside prompt_toolkit's patch_stdout context, which intercepts all stdout writes. Raw ANSI escapes from Rich get swallowed or mangled by patch_stdout's StdoutProxy — we've hit this repeatedly and have an entire adapter layer (ChatConsole, _cprint) to work around it for basic output. Rich Markdown rendering generates significantly more complex ANSI than what we currently route through that pipe (24-bit color codes, nested formatting, syntax highlighting, box drawing), and there are known edge cases where prompt_toolkit's ANSI() parser doesn't handle them correctly.

We have this scoped as Issue #504 (Enhanced CLI TUI) — it's planned as a phased core codebase change because getting markdown rendering right under prompt_toolkit requires careful integration with the streaming output, terminal compatibility handling (SSH, tmux, mosh), and performance testing. It's a harder problem than it looks on the surface.

There's also a merge conflict with the skin engine work that landed on main since this PR was opened, which customizes the response box branding/colors.

The concept is solid though — when we do tackle #504, the approach of rendering Rich Markdown into a Panel and routing through _cprint is a reasonable starting point. Appreciate the contribution!