feat(setup): --reuse-credentials skips browser authorization while keeping every platform check

[itswl]

What

Re-running larkin setup for an already-authorized app always required another platform authorization (QR / confirmation page), even though the bot credential was already on disk. The registration entry only had three paths — --from-cli-profile + LARKIN_SETUP_APP_SECRET, the Lark /page/cli QR flow, and the Feishu authorization page — with no branch that reuses stored credentials. Filed as #221; this implements direction 1.

Change

• src/setup/bot-register.ts: new --reuse-credentials branch. It loads the selected Agent's credential through loadValidatedBotCredential (the same validator other flows use) and feeds it into the existing post-authorization pipeline exactly as if it had just been returned by the platform. Everything downstream is unchanged:
  • bot identity is still verified through the managed bot-only lark-cli (im +chat-list --as bot);
  • the required-tenant-scope gate still reads GET /open-apis/application/v6/scopes and dies unless grant_status=1 — the fail-closed semantics from [Bug] Lark setup 绿过 +chat-list 后仍缺 im:message.group_msg，群/thread 历史读取 230027，freshness gate 无法发送 #160/[Bug]: Lark setup 附加权限未生效，既有应用补授权 URL 丢失 clientID #210 are preserved, so a missing grant still blocks and points at the developer console;
  • document-comment subscription reconciliation, the atomic 0600 credential write, and the same-App-ID bind all run as before.
  • The flag fails fast when no valid stored credential exists, rejects an explicit --tenant that contradicts the stored tenant before any write, and refuses to combine with --from-cli-profile.
• src/app/setup.ts: flag passthrough plus help text.
• test/integration/setup/setup-reuse-credentials.test.mjs: four cases — reuse skips the authorization page and still fails closed on a denied scope (the injected registerApp throws if the QR path is ever taken, and the injected QR generator writes a marker file that the test asserts is absent), a green path that completes the whole flow (bot identity, grants, visibility, bind, result file) with the authorization page never requested, a missing credential fails with a clear message before any authorization, and an explicit tenant contradiction aborts before writing.

Note on the interactive runtime prompt: with --runtime omitted, the run still shows the existing-agent prompt (已有 Agent：claude/default。直接回车保留；输入 c 才修改), so the stored runtime is kept on Enter; pass --runtime to skip the prompt entirely. This PR lands ahead of maintainer alignment on #221 — happy to adjust the shape, split it, or park it.

Validation

• bun test test/integration/setup/setup-reuse-credentials.test.mjs → 4 pass / 0 fail
• bun test test/unit/setup/ test/unit/app/setup-cli.test.mjs test/integration/setup/ → 79 pass / 1 skip / 1 fail. The failure (setup-single-root.test.mjs: "a clean shell build emits loadable setup-binding.mjs with the pure planning export") is environmental on this machine: it performs a full clean build inside bun's default 5 s test timeout, and a clean build measures ~11.4 s here. Unrelated to this change.
• bun run build ✅ · bun run typecheck ✅ · bun run licenses:check ✅ · bun run publication:check:tree ✅
• bun run test:integration (CI pre-check on this branch) → 182 pass / 18 skip / 7 fail. All 7 failures are clean-build / build-graph / hook-timeout cases that reproduce on unmodified main in this environment — a clean build measures ~11.4 s here while the affected tests budget 5 s.
• bun run test:unit → 895 pass / 1 skip / 1 fail. The single failure is the pre-existing environmental three-Agent live acceptance is opt-in, hermetic by default, and fixture-verifiable, which also fails on unmodified main here. (An earlier run under heavy concurrent load showed extra timeout failures in process-spawning tests; each of those files passes in isolation — 37 pass / 0 fail — so they were load artifacts, not regressions.)

Refs #221

🤖 Generated with Claude Code

[eddiearc]

HOLD（Fable 5.1 审合）— 等 #221 Owner 定案 + 两处改动

实现方向 1 很稳：跳过授权页，但 Bot 身份、grant_status 门禁、订阅 reconcile、写盘与同 App 绑定全保留；缺凭证 / --tenant 冲突 / 与 --from-cli-profile 互斥都有 fail-fast。集成测质量高。

合前必须：

1. Owner 对齐 #221（flag vs 自动复用等）
2. resolveSelectedTenant() 在 reuse 分支之前仍会弹「选择平台」——reuse 检查应挪到 prompt 前
3. help 文案写明 reuse 不会重跑 registerApp / LARKIN_REGISTER_ADDONS

缺 version bump；与 #226 有 import 行冲突。

[eddiearc]

Maintainer follow-up — HOLD

实现质量不错（保留 bot 身份 / grant 门禁 / reconcile / 写盘），但 先等 #221 产品定案，再合。

合前还请改：

1. --reuse-credentials 时，先读存量凭证并推断 tenant，不要先弹「选择平台」再静默覆盖。
2. 与 --from-cli-profile 等互斥检查放到交互之前。
3. help 写明：reuse 不会重跑 registerApp / LARKIN_REGISTER_ADDONS。
4. 补上 public larkin setup 入口测（现在多半直接打 bot-register）。

这是 setup 便利性功能，不是本轮 runtime 修复的前置。

[itswl]

四条已改（head 993a4c0，已 rebase 到最新 main；HOLD 我们理解——等 #221 产品定案后再请审）：

1. tenant 改为取自存量凭证：--reuse-credentials 时先读 bots/<App ID>.json（loadValidatedBotCredential）并由其推断租户，不再弹「选择平台」；显式 --tenant 与之冲突时在任何写入前中止，非法值同样先拒。
2. 互斥检查前置：--reuse-credentials × --from-cli-profile 在任何交互之前失败（bot-register 内前置，公共入口 setup.ts 另加一道早退）。
3. help 已写明：不重跑 registerApp / LARKIN_REGISTER_ADDONS，且租户来自存量凭证而非询问。
4. 补了 public 入口测：setup --reuse-credentials --from-cli-profile x（非 TTY）→ 断言在接触 lark-cli 之前就失败。

验证：setup-cli + setup-reuse-credentials 两个测试文件 10 pass / 0 fail；build / typecheck 通过。

[eddiearc]

复看 head 993a4c0：上次四条代码改动都到位了。

1. ✅ reuse 先读存量凭证推断 tenant，不弹「选择平台」
2. ✅ 与 --from-cli-profile 互斥前置（setup + bot-register）
3. ✅ help 写明不重跑 registerApp / ADDONS、租户来自存量凭证
4. ✅ 公共入口测已补

仍 HOLD：等 #221 产品定案（要不要这个 flag / 是否默认自动复用）。代码侧就绪后即可再叫合。

[itswl]

package.json 已按 Owner 政策补 bump（0.5.9 → 0.5.10，head 6a3807a）；代码侧维持上轮结论，继续 HOLD 等 #221 定案。

[itswl]

source-checks 失败排查（head 6a3807a）

失败项只有 test/e2e/pi-prompt-preflight-recovery-mock-e2e.test.mjs 的 production RuntimeHost RPC events manual success plus exact second overflow fallback once without duplicate delivery（2 s waitUntil 超时；21 pass / 1 fail）；Windows gate 与 standalone artifact 均通过。

• 同一分支 12 小时前（01:50Z）的 source-checks 全绿；同批次 fix(runtime): let the pi process verdict win over a failed write #224/fix(feishu): unregister the default card handler before replacing it (node-sdk 1.74) #231/feat(runtime): surface allow-listed provider finish reasons in status recent errors #233 的 source-checks 刚全绿；
• 本机在未改动的 main 上单独跑该文件同样失败（稳定复现），与本 PR 内容无关；
• 本 PR 只改 setup/bot-register，不触及 Pi runtime 恢复路径。

应属 CI 时序抖动，烦请重跑一次。