Adds Feishu support for the existing clarify primitive — agents can ask the user a question and render up to 4 tappable buttons (plus an ✏️ Other fallback) instead of forcing a typed reply. Mirrors the existing Telegram/Discord implementation; reuses tools/clarify_gateway.py end-to-end.

What

• send_clarify(...) builds an interactive card with one button per choice. Picking a choice resolves the clarify; picking Other flips the card into text-capture mode so the next message becomes the response. Open-ended (no choices) renders as plain markdown and the existing text-intercept handles it.
• _handle_clarify_card_action(...) authorizes the operator (_is_interactive_operator_authorized), looks up the question via tools.clarify_gateway._entries, and replaces the card with a resolved/awaiting variant.
• _resolve_clarify(...) schedules the unblock first and only then drops state, so a missing event loop leaves the entry recoverable on retry.
• _escape_lark_markdown(...) sanitizes **, _, [, ], ` in user-controlled question / choice / user_name fields before interpolation into Lark markdown.

Why

Feishu was the only major adapter without send_clarify, so any clarify call from an agent fell back to the plain-text path even though Feishu cards render great. CARD-ONLY workflows now stay structured all the way through.

Notes

• New button namespace hermes_clarify_action (avoids collision with the existing hermes_action approval namespace).
• Single-file change: gateway/platforms/feishu.py (+236 lines).
• No new deps. No schema or contract changes to clarify_gateway.

Test plan

Manual on a live Feishu deploy:

• ✅ Multi-choice card renders with numbered buttons.
• ✅ Click resolves agent + replaces card with green confirmation.
• ✅ Other flips to awaiting card; next typed message resolves.
• ✅ Open-ended (no choices) renders question and the typed-text path resolves.
• ✅ Question containing **, _, [ ], ` renders intact (escape verified).
• ✅ Unauthorized operator click is rejected silently.