fix: keep markdown tables block-level

[Michaelyklam]

Thinking Path

• Hermes WebUI chat rendering should handle common Markdown output shapes without requiring users to inspect raw syntax.
• Pipe tables were already converted to <table> markup, but the final paragraph pass did not treat generated tables as block-level output.
• The fix is to keep generated tables isolated and add table to the paragraph-wrap skip list so valid CommonMark tables stay as tables.

What Changed

• Keeps renderer-generated tables separated with blank lines before paragraph splitting.
• Treats <table> like other block elements in the paragraph-wrap skip list.
• Adds Node-backed regression coverage using the actual renderMd() implementation for a standalone table and a table between paragraphs.
• Adds a changelog entry for bug: Markdown tables not rendering — table HTML wrapped in <p> tags #2374.

Why It Matters

• Agent responses that include Markdown tables now render as actual HTML tables instead of raw pipe-delimited text or invalid paragraph-wrapped table markup.
• The regression test exercises the real browser renderer path rather than a Python mirror.

Verification

• /home/michael/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_renderer_js_behaviour.py -q — 45 passed
• node --check static/ui.js
• git diff --check

Risks / Follow-ups

• Low risk: the change is limited to the existing Markdown table rendering path and final paragraph-wrap block allowlist.
• No follow-up expected unless additional CommonMark table variants need broader parser support.

Closes #2374

Model Used

AI-assisted change with repository inspection, targeted editing, and shell-based test verification.

[nesquena-hermes]

Reading the diff against origin/master and the surrounding renderMd() flow in static/ui.js — the fix addresses two compounding issues that together produce the <p><table>...</table></p> symptom from #2374.

Issue 1: table emission missing blank-line separation

On master, static/ui.js:2608-2618 emits the table as a bare HTML string:

return `<table><thead>${header}</thead><tbody>${body}</tbody></table>`;

If the table sits between text paragraphs, the final paragraph splitter (/\n{2,}/) treats the table and adjacent text as one "paragraph" because there's no guaranteed blank line on either side of the substituted HTML. The PR's two \n\n bookends on the return value are the same pattern already used elsewhere in this renderer (see the comment at static/ui.js:2355-2357 for the bold/emphasis splitter case). That pattern is consistent with the file.

Issue 2: paragraph-wrap skip list missing table

static/ui.js:2760 on master:

s=parts.map(p=>{p=p.trim();if(!p)return '';if(/^<(h[1-6]|ul|ol|pre|hr|blockquote)|^\x00[EQ]/.test(p))return p;return `<p>${p.replace(/\n/g,'<br>')}</p>`;}).join('\n');

The skip list (h[1-6]|ul|ol|pre|hr|blockquote) lacks table. So even when blank lines isolate the table block, the splitter still wraps it in <p>...</p>. Adding table to that alternation, which is what the PR does, is the right surgical fix.

Both fixes are needed: skip-list alone wouldn't help if the table got glued to surrounding text by the lack of blank-line bookends; bookends alone wouldn't help if the isolated block still hit the paragraph wrap.

Tests

tests/test_renderer_js_behaviour.py already drives the actual renderMd() via Node (_render(driver_path, src)), so the two new tests exercise the real renderer:

def test_commonmark_table_is_not_wrapped_in_paragraph(self, driver_path):
    ...
    assert "<p><table" not in out, (...)

def test_table_between_paragraphs_stays_block_level(self, driver_path):
    ...
    assert "<p>Before the table.</p>" in out
    assert "<table><thead>" in out
    assert "<p>After the table.</p>" in out
    assert "<p><table" not in out
    assert "</table></p>" not in out

The CJK fixture in the first test (升级时段, ~30 人) is a nice touch — it covers the original report's content shape exactly.

Risk notes

• <table> is now in both the SAFE_TAGS allowlist (static/ui.js:2640) and the paragraph-wrap skip list, which is internally consistent.
• The skip-list regex anchors on ^<(...) — so any table that ends up not at the start of a parts.map chunk (after trim) would still be wrapped. The blank-line bookends in the table-pass replacement guarantee a fresh \n\n boundary, which is why both halves are needed.
• No interaction with the CSV-table pass (static/ui.js:2463) because that one emits a <div class="csv-table-wrap"> wrapper, not a bare <table>.

LGTM. Two-line fix with two real-renderer regression tests.