feat(feishu): send markdown tables as interactive cards

[yiyouguisu]

Problem

Feishu's md renderer hides content inside Markdown tables — rows after the header/separator become invisible. Users reported that "标题下内容看不到" (content under headers is not visible).

Hermes only used the post / md tag for rich text, which does not support tables. Meanwhile the interactive card format renders tables correctly.

Solution

Add automatic card dispatch for content containing Markdown tables:

New functions:

• _table_block_present() — detect real table blocks (≥2 contiguous |…| lines outside code blocks)
• _build_markdown_card_payload() — wrap content in a Feishu interactive card ({"tag": "markdown", "content": …})
• Regex patterns _TABLE_ROW_RE, _TABLE_SEP_RE for table detection

Message routing (_build_outbound_payload):

1. Content has a table block → "interactive" (card) — tables render correctly
2. Otherwise → "post" / "text" (existing logic)

Fallback chain (both send() and edit_message()):

• interactive → post (table sanitization: converts to bullet lists)
• post → plain text (existing fallback for invalid post)

This ensures content is never lost: best case is a rendered card, worst case is a bullet list.

Related

• sanitize_markdown_table already existed in the Yuanbao adapter but was never ported to Feishu
• This PR adds it as _sanitize_markdown_tables() (the post-pipeline safety net)
• Additionally adds the card-based primary path that preserves table structure

Testing

• Content with tables → card is sent
• Content without tables → post/text (unchanged behaviour)
• Tables inside code blocks → not detected as tables
• Single pipe lines (e.g. inline |code|) → not detected (requires ≥2 rows)
• Card failure → falls back to post with table-to-list sanitization

[alt-glitch]

Related to #18756. Competes with #12114, #15956, #16194, #19038 — all addressing the same Feishu markdown table rendering problem with different approaches.

[alt-glitch]

Related to #18756. Competes with multiple PRs.

[marsdream]

Confirmed. We hit this exact issue — Markdown tables sent via Hermes to Feishu render as garbled plain text. Our local patch using interactive (Card) + tag: markdown matches this PR's approach and verified working. Attaching a screenshot of the rendered table vs the broken fallback.

Local verification:

• msg_type=interactive with Card schema 2.0 + tag: markdown renders tables correctly in Feishu
• Tables detected via |.+\|[\r\n]+\|[-:| ]+\| regex pattern
• Fallback: if Card send fails, tables degrade to bullet lists (never silently dropped)

This PR solves the problem. Adding P2 label seems appropriate given the severity. 👍

[teknium1]

Thanks for preserving table content and documenting the card fallback approach. Current main now avoids the original blank-table symptom with text routing in plugins/platforms/feishu/adapter.py:4524-4534, so this should be treated as a structured-rendering enhancement rather than a direct restoration of the old path.

Problems

• The advertised interactive → post → text chain is incomplete. After the interactive exception fallback at gateway/platforms/feishu.py:1828-1836, the response fallback at :1839-1851 still checks the original msg_type == "post"; it remains "interactive". A rejected post fallback therefore does not degrade to text. edit_message() likewise stops after interactive → post at :1900-1908.
• The PR changes the legacy adapter path, while current main migrated Feishu to plugins/platforms/feishu/adapter.py (560010547; active routing at :4524-4534). The implementation and coverage need to target that active surface.

Suggested changes

• Use a shared fallback helper/state transition so both send and edit retry post failure as text, including exception and unsuccessful-response cases.
• Port the change to the plugin adapter and add focused gateway tests for the routing and both fallback stages.

Automated hermes-sweeper review.

[teknium1]

This post fallback is not followed by the post-to-text fallback below: msg_type remains "interactive", so the guard at lines 1839-1851 is skipped if this post response is rejected. Track the effective fallback type or route retries through a helper that can continue to text.

[teknium1]

The edit path also stops after interactive → post; if that post update fails, it returns the failed result rather than the claimed final text fallback. Apply the same complete fallback state handling here.