auth login --domain slides 暴露了 slides 域，但当前 app 未开 slides:* 时缺少清晰诊断

问题

从用户视角看，lark-cli 会让我认为 slides 能力已经可用：

1. lark-cli auth login --help 的 --domain 可选值里包含 slides
2. lark-cli slides --help 已经暴露了 +create、+media-upload、+replace-slide、xml_presentations 等命令

所以用户很自然会尝试：

lark-cli auth login --domain slides
lark-cli slides +create --as user --title "test"

但如果当前配置的开放平台 app 没有开任何 slides:* scope，这条路径实际不可用。这里容易混淆：CLI 支持 slides，不等于当前 app 能申请/使用 slides scope。

## 当前验证结果

环境：

lark-cli version 1.0.39
brand=feishu
tokenType=user

已验证：

lark-cli auth login --help

输出里 --domain 可选值包含：

slides

并且：

lark-cli slides --help

存在 slides 相关命令。

但当前 app scope 查询结果是：

lark-cli auth scopes --format json

解析结果：

userScopes_count=125
slides_scopes_count=0
slides_scopes=<none>

执行 dry-run：

lark-cli slides +create --dry-run --as user --title "scope probe"

返回：

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "missing_scope",
    "message": "missing required scope(s): slides:presentation:create, slides:presentation:write_only",
    "hint": "run `lark-cli auth login --scope \"slides:presentation:create slides:presentation:write_only\"` in the background. It blocks and outputs a verification URL — retrieve the URL and open it in a browser to
complete login."
  }
}

## 困惑点

这里实际上有三层状态：

- CLI 支持 slides domain：已验证
- CLI 支持 lark-cli slides ... 命令：已验证
- 当前 app 是否在开放平台开通了 slides:* scope：当前没有

但当前错误提示主要引导用户继续跑 auth login --scope ...，没有明确说明“当前 app 后台可能没有开通这些 scope”。如果 app 本身没开，继续授权也解决不了。

## 期望

希望 CLI 能在这类场景给出更明确的诊断：

1. 区分“CLI 支持 slides”和“当前 app 没有开 slides scope”
2. 当 auth scopes 里没有任何 slides:* 时，提示用户去开放平台权限管理里开通对应 scope
3. 对 --domain docs,wiki,sheets,base,slides,... 这种批量授权，最好能提前指出是哪一个 domain/scope 不在当前 app 白名单里
4. hint 不只建议 auth login --scope ...，也建议检查：

lark-cli auth scopes --format json

## 影响

这会影响 AI agent / harness 的一次性授权流程。只要批量 --domain 里包含一个当前 app 未开通的 domain，比如 slides，用户可能会被整个授权流程卡住，但很难判断是 CLI 不支持、用户 token 缺 scope，还是 app 后台没开权限。

Start by running lark-cli auth scopes --format json and the lark-cli slides +create --dry-run --as user flow described in the issue, then trace the existing missing-scope diagnostic behind auth login --scope. Done means the diagnostic distinguishes CLI support from app-enabled scopes, points users to app permission management, and identifies unsupported domains or scopes during batch authorization.