fix(workspace): resolve large markdown preview fallback and add force-render button

[starGazerK]

Thinking Path

• Hermes WebUI's workspace panel should preview ordinary Markdown documents without making users drop into raw text too early.
• The existing rich Markdown limits (64 KB / 1500 lines) were conservative enough that moderately sized docs, such as an 85 KB / 2500-line file, fell back to plain text.
• The fallback guard is still useful for genuinely large files because renderMd() and KaTeX enhancement can jank the browser main thread.
• This PR keeps the guard, raises the default thresholds, and adds an explicit per-file escape hatch for users who want to rich-render an oversized Markdown file anyway.
• Manual testing also exposed that the backend /api/file text read limit (200_000 bytes) was lower than the new rich-render byte limit, so the API could reject a file before the frontend fallback could run. The read limit is raised conservatively to 400_000 bytes so large Markdown fallback can work.

What Changed

• Raised workspace Markdown rich-render defaults in static/workspace.js:
  • MD_PREVIEW_RICH_RENDER_MAX_BYTES: 64 * 1024 -> 256 * 1024
  • MD_PREVIEW_RICH_RENDER_MAX_LINES: 1500 -> 5000
• Added a Render as markdown anyway preview-header action for Markdown files that still exceed the guard.
• Threaded a forceRichMarkdown option through openFile() so the same loader can bypass the plain-text gate only after explicit user action.
• Preserved _previewRawContent and reused it for the force-render path so forcing rich render does not need a second fetch.
• Kept KaTeX enhancement on the force-render path through the shared renderMarkdownPreviewContent() helper.
• Raised MAX_FILE_BYTES from 200_000 to 400_000 so /api/file can still return Markdown content that needs client-side plain-text fallback.
• Updated ARCHITECTURE.md, CHANGELOG.md, and tests/test_issue2823_large_markdown_preview.py.

Why It Matters

• Markdown files slightly above the old limit now rich-render automatically.
• Very large Markdown files still avoid accidental main-thread jank by default.
• Users now have an obvious per-file opt-in instead of a dead end that only offered raw editing.
• The frontend and backend limits are aligned enough that client-side fallback can actually run for files above the rich-render threshold.

Verification

• pytest tests/test_issue2823_large_markdown_preview.py -v
  • Result: 9 passed
• node --check static/workspace.js
  • Result: passed
• pytest tests/test_issue347.py -k "workspace" -v
  • Result: 3 passed, 31 deselected

Manual browser verification:

• Started server.py in an isolated WSL test state with HERMES_WEBUI_AGENT_DIR pointing at a missing path, matching the project browser-smoke agent-free pattern.
• Opened the workspace panel and tested:
  • small.md (~0.1 KB): rich-rendered automatically.

- `medium-85kb.md` (~122 KB): rich-rendered automatically. - `huge-over-limit.md` (~228.5 KB / over 5000 lines): fell back to plain text and exposed `Render as markdown anyway`. - Clicking `Render as markdown anyway` switched the file to rich Markdown rendering.

Risks / Follow-ups

• Force-rendering genuinely huge Markdown can still jank the browser, but it now requires an explicit user action.
• MAX_FILE_BYTES is raised to 400_000, which is intentionally above the new 256 * 1024 rich-render threshold.
• Server-tunable Markdown preview limits remain out of scope because these thresholds live in the browser bundle and would require boot-time client config plumbing.

Model Used

• AI-assisted with OpenAI Codex (GPT-5.5) in the local repository.

[nesquena-hermes]

Shipped in v0.51.228 ✅ — cherry-picked onto release stage-p12. Large markdown docs now preview as rich markdown up to 256KB/5000 lines (backend read 400KB), with a 'Render as markdown anyway' button above the limit. Two review fixes were folded in: force-render now refreshes the cached raw content on save (no stale pre-edit render) and is path-scoped (no wrong-file render after a switch) + blocked while the editor is dirty. Thanks @starGazerK! Closing as merged-via-release. (Closes #3378.)