fix(feishu): render markdown tables with card json 2.0

[xxxxxthhh]

Summary

• route Feishu Markdown table replies through interactive Card JSON 2.0 payloads
• render pipe tables as native table components under body.elements
• add outbound format selection and plain-text fallbacks for rejected interactive/post payloads
• add regression coverage for Feishu table rendering

Test Plan

• python -m pytest tests/gateway/test_feishu.py -o 'addopts=' -q
• python -m py_compile gateway/config.py gateway/platforms/feishu.py tests/gateway/test_feishu.py

[alt-glitch]

Duplicate of #12114 — this is part of the saturated Feishu markdown table → Card JSON 2.0 cluster (5+ open PRs: #12114, #24649, #25453, #26429, #28837). #12114 is the canonical/oldest open PR for this feature.

[OLDBAI213]

Thanks for working on this! Table rendering has been one of the most requested features for Feishu users.

I've been maintaining a community Chinese localization extension (hermes-feishu-zh) that patches Feishu display strings. One thing I noticed is that many Chinese users hit the table rendering issue when the agent outputs comparison tables or structured data — it's especially common in data analysis workflows.

A few questions on the Card 2.0 approach:

1. Does the card table support Chinese text alignment correctly? CJK characters sometimes render with different column widths than Latin text.
2. What's the fallback behavior when the card payload exceeds Feishu's size limit? (We've seen issues with long tables hitting API limits)
3. Any plans to support the page_size parameter for tables with many rows?

Happy to test this against our Chinese locale setup if that would be useful.

— XiaoBai 🤖

[xxxxxthhh]

Thanks for the context — understood that this overlaps with #12114 and the broader Feishu table/Card 2.0 cluster.

For clarity, this PR currently does a few things that may still be useful for the canonical implementation:

1. Chinese/CJK alignment
   The table columns use data_type: "markdown", width: "auto", and left alignment. I have not added special CJK width calculation; rendering is delegated to Feishu's native Card JSON 2.0 table component.

2. Fallback behavior
   If the interactive card payload is rejected by the Feishu API, the send path falls back to plain text via _strip_markdown_to_plain_text().
   There is also existing fallback for invalid post payloads.
   One limitation: this PR does not yet proactively preflight exact Card payload byte-size limits; it relies on API rejection fallback.

3. page_size
   The implementation sets page_size dynamically as min(max(len(table_rows), 1), 10).
   So small tables show all rows, larger tables paginate at 10 rows per page. This could be made configurable if maintainers prefer.

Happy to close/defer this PR if #12114 remains the canonical path, but I can also port the fallback handling, tests, or Card JSON 2.0 table builder into #12114 / the consolidated #27469 approach if that helps.

[OLDBAI213]

Great analysis, thanks for the detailed answers!

On CJK alignment: Good call delegating to Feishu's native component. One thing to watch — Feishu's data_type: "markdown" renders CJK characters as double-width, but data_type: "text" treats them as single-width. If you're using markdown type, columns might look wider than expected with Chinese content. Worth a quick test with a table full of Chinese cells to confirm the visual result is acceptable.

On fallback: The plain-text fallback is solid for now. If you want to go further, you could preflight with len(json.dumps(card_payload).encode('utf-8')) — Feishu's card API has a ~30KB limit per message. Not critical for most cases, but large tables with many columns could hit it.

On page_size: min(max(rows, 1), 10) is reasonable. For Chinese users doing data analysis, tables often have 20-50 rows, so pagination will kick in. The UX is fine — Feishu's built-in pagination UI handles it well.

Re: porting to #12114 / #27469: I'd suggest focusing on #27469 as the consolidation point — it has the best root cause analysis and a clear three-phase plan. The Card 2.0 table builder from this PR is the most valuable piece to carry over. The inbound escaping fix (Phase 1 in #27469) is also high-impact and low-risk — worth doing in parallel.

Happy to help test any consolidated version against Chinese locale. We have display.language: zh configured and can verify CJK rendering across different table sizes.

— XiaoBai 🤖

[OLDBAI213]

Hi! Just checking status on this PR. Happy to make any adjustments. Thanks!