Improve diagnostics for Feishu app/profile mismatch causing low-signal API errors

Summary

When a lark-cli profile is bound to a different Feishu/Lark app than the app that originally produced the target chat/message/user IDs, several commands fail with very generic API errors such as:

• TAT API error: [10003] invalid param
• open_id cross app
• message recall errors where the active bot is "not the sender"

The root cause can be an app/profile mismatch, but the current diagnostics do not make that obvious. This is especially easy to hit in agent or multi-profile setups where ~/.lark-cli/config.json, ~/.lark-cli/<workspace>/config.json, and the host application's app credentials may diverge.

Environment

• lark-cli version observed: 1.0.30
• OS: WSL Ubuntu
• Brand: Feishu
• Workflow: Hermes Agent + lark-cli, using bot identity for sending/recall and user identity for reads/docs

What happened

A stale lark-cli profile was still bound to an older app. Commands such as bot chat lookup, bot send, or message recall failed with low-signal errors, even though request shape/dry-run looked fine.

Examples of observed symptoms:

TAT API error: [10003] invalid param

open_id cross app

No permission to recall this message ... The bot is neither the sender

After rebinding the profile to the same app used by the host/gateway app, the diagnosis became clear and the right next step was to re-check user/bot auth and scopes.

export LARK_CLI_NO_PROXY=1
lark-cli config show
lark-cli auth status --verify
lark-cli auth scopes
lark-cli config bind --source hermes --identity user-default --force
lark-cli config show

Why this is hard to debug

The API error looks like a bad chat_id, message_id, or request parameter, but in practice the problem may be that IDs/tokens belong to another app context.

For agent-driven workflows this causes repeated retries of the wrong layer:

1. Validate payload with dry-run
2. Retry send/recall/list
3. Change chat/message IDs
4. Eventually discover the active app/profile is different

Proposal

Improve diagnostics when lark-cli sees these app-scoped identity failure patterns:

1. For open_id cross app, print a hint to check the active profile/app:

   lark-cli config show
   lark-cli auth status --verify
   

2. For Feishu API 10003 invalid param during chat/message/user operations, consider adding a generic hint:

   If this ID came from another app or profile, re-check lark-cli config show and re-resolve the ID under the active app.

3. For recall/delete failures where the bot is not the sender, mention that Feishu treats different app IDs as different senders even if both are bots.
4. Optionally add a doctor or doctor preflight check that surfaces the active app ID, workspace/profile path, and identity readiness before write operations.

Expected behavior

The CLI should not mask the raw Feishu API error, but it should add a short actionable hint that app/profile mismatch is a likely cause for these specific failures.

Start by tracing the commands and error patterns described in the issue: config show, auth status --verify, auth scopes, chat/message/user operations, and recall/delete failures. Preserve the raw Feishu error while adding actionable app/profile-mismatch hints, and verify that the suggested checks cover open_id cross app, API 10003, and bot-not-sender failures.