enhancement(im): enable agent-driven interactive card input and clicks

Problem

lark-cli can send and read interactive cards and can consume the card.action.trigger event after a real user interacts with a card, but it cannot drive an existing card in a chat as a user or test agent.

There is no CLI workflow for operations such as:

• locating an interactive card message in a chat and clicking a button;
• filling an input field or submitting a form;
• selecting an option in a dropdown, checkbox, or date/time control;
• capturing the resulting callback and updated card state as one automation flow.

Impact

When debugging a Feishu bot that uses interactive cards, an agent cannot complete the test loop by itself. The agent has to ask a human to open the chat, fill the card, and click the controls, which makes automated debugging and end-to-end verification slow and non-deterministic.

Current behavior

Environment checked on 2026-08-31:

• lark-cli version: 1.0.73
• lark-cli im --help exposes message send/read operations, but no command for driving controls on an existing interactive card.
• lark-cli event schema card.action.trigger documents button clicks, form submits, dropdown selects, and similar interactions as events emitted after a user action. It provides an event-consumption path, not a card-control driver.

The existing issues #420 and #1624 cover callback/button errors and bridge-token handling, respectively. This request is about the missing agent/test automation capability for performing the interaction itself.

Expected behavior

Provide a supported CLI capability for deterministic interactive-card testing and automation. The capability should be able to target a card message and express control actions, including button clicks and form/control values, then expose the resulting callback and card update/state so an agent or CI job can continue without manual client interaction.

Please clarify the supported identity and permission model, and whether this should operate against real chat messages, a local/test card harness, or both.

Reproduction / validation scenario

1. Use lark-cli to send an interactive card containing an input field, a dropdown, and a button.
2. Attempt to complete the card from the CLI by filling the input, selecting the dropdown value, and clicking the button.
3. Observe that the CLI has no command or documented API to perform these actions; a human must use the Feishu client.
4. Consume card.action.trigger only after the human action and handle the callback.

Root cause status

unknown — this issue records the missing user-facing CLI capability; the implementation boundary and Feishu platform API support need to be determined by the maintainers.

{
  "captured_at": "2026-08-31T10:03:24Z",
  "repository": "larksuite/cli",
  "incident_head": "unavailable",
  "branch": "unavailable",
  "dirty": false,
  "root_cause_status": "unknown",
  "builder_loop_runtime": {
    "builder_loop_version": "0.1.0",
    "adapter": "codex",
    "adapter_commit": "c03f50bb8e1835561eae8918432f02ede36bc262",
    "adapter_dirty": false,
    "capture_status": "captured"
  }
}

Start with the existing lark-cli im --help commands and the documented card.action.trigger event schema. Determine whether Feishu provides an API for acting on existing card controls, and clarify the supported identity and permission model and whether real messages, a local harness, or both are in scope. Done means a decided implementation boundary and a validated automation flow for control actions, callbacks, and updated card state.