mail user_mailbox.drafts create: --help advertises `--as bot` but the command rejects it

What happens

$ lark-cli mail user_mailbox.drafts create --help
      --as string   identity type: user | bot

Passing --as bot is then refused by the command itself, before any API call:

$ lark-cli mail user_mailbox.drafts create --user-mailbox-id someone@example.com --as bot --dry-run
{
  "ok": false,
  "identity": "bot",
  "error": {
    "type": "validation",
    "subtype": "invalid_argument",
    "message": "--as bot is not supported, this command only supports: user",
    "param": "--as"
  }
}

Note it is rejected with --dry-run, so this is the CLI's own validation, not the server's.

Why it matters

We were deciding whether an app could write drafts into a user's mailbox with tenant credentials, or whether the mailbox owner has to complete an OAuth flow. The help text says app identity is available, so we built on that assumption and only found out at execution time.

For comparison, mail +send --help correctly shows identity type: user only — so the shortcut documents the constraint and the underlying command does not.

Expected

Either accept --as bot (if the API supports app tokens for this endpoint), or list only user in --help, matching mail +send.

The second is presumably correct: mailbox contents are personal data, and Feishu appears to require the owner's own authorization. Worth stating that in the command's help — "user only; the mailbox owner must authorize" would have saved the round trip.

Version

lark-cli skills 1.0.80, binary 1.0.83

Start at the mail user_mailbox.drafts create command entry point and compare its --as help with mail +send --help. Find where the identity options and validation are defined, then make the advertised options match the accepted behavior and explain the user-only constraint. Verify with the shown --help and --dry-run commands.