PR #4811 需要维护者确认：Luna 账户级 reserve 路由与额度展示

[MagicLizi]

PR #4811 为本地 Codex Luna 会话增加账户级 reserve 路由：普通额度耗尽后，仅在账户明确声明支持、且预留桶属于当前所选模型时，把 turn/start 的 wire model 改成 gpt-reserve，同时不改用户已保存的模型选择。

这不是既有行为的 bugfix 或机械补充，因此需要维护者确认后再审合并。

本次改动

• 账户额度读取声明 supportsLunaReserve，并把 per-limit 桶表、可选 normalModelSlug 带到 desktop usage 投影和 mobile 兼容 snapshot。
• maker-core 在本地 Luna / account-OAuth 路径上解析资格；gateway 与 SSH 远程不探测本机账户预留。
• 额度读取在后台进行、session 内按 provider/account 缓存 30 秒并设 5 秒上限；发送路径只用已解析快照，不在 handle.send 上等待额度。
• 现有 usage 展示可在普通额度耗尽后选中模型专属预留桶；无新布局、控件或可选模型。

为何需要确认

1. 产品 / UI：feat 且命中 apps/desktop/src/renderer/hooks/useAccountUsage.ts。额度耗尽后的展示与实际发送路由都会变，影响用户能看到和用到的 Luna 行为。
2. 架构：核心路径改动约 422 行（packages/maker-core Codex 路由、maker-shared 额度桶、desktop usage 持久化、device-link snapshot 类型）。这是账户级能力协商与 wire routing，不是纯技术整理。

请维护者直接在 PR 上 Approve 放行；若当前 head 还需要作者修改，请 Request Changes。确认后仍须通过独立代码审查、未解决 thread 与 CI，不会仅因本讨论结束而合并。

Native runtime 与真实有资格账户的验收，作者已标明未做；runtime pin 未改。

---

关联 PR:#4811(作者 @thatlev);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：Luna 账户级 reserve 能在普通额度耗尽后继续利用账户明确提供的模型专属额度，同时保留用户已选模型和现有账号边界，具有明确用户价值，值得继续推进。当前不建议直接批准 PR #4811：在进入产品放行前，应先修复额度快照一致性问题，并完成真实有资格账户的端到端验收。\n\n行动建议：\n1. 对 PR #4811 Request Changes，而不是仅以产品确认评论放行。\n2. 修复 normalModelSlug 在完整快照、桌面持久化快照、renderer 状态以及 account/rateLimits/updated 稀疏合并链路中的字段声明和保留规则。部分更新缺少该字段时，应保留同一 limitId 桶已有的模型绑定；只有明确的权威全量数据或账号/桶切换时才替换或清除。\n3. 在修复后复跑相关 unit gate、Desktop/Mobile typecheck 和 CI，并增加反证测试：完整读取写入模型绑定后，分别收到只带 primary、只带 secondary、无 normalModelSlug 的合法稀疏更新，绑定仍可用于模型选桶；账号切换、清空和旧 payload 兼容仍成立。\n4. 用真实有资格账户验证：普通额度可用时仍走普通 Luna；普通额度耗尽且 reserve 属于当前模型时，turn/start 才使用 gpt-reserve；无资格、缺字段、错误模型桶、gateway、SSH 和冷缓存均不误用 reserve；保存的用户模型、effort 和账号隔离保持不变。\n5. 单独验证 reserve 额度展示、桌面与移动兼容 snapshot，以及 desktop/mobile 混合版本行为。作者已明确 Native runtime 和真实有资格账户验收尚未完成，因此自动测试通过不能替代这些验证。\n\n已确认的代码事实：\n- 当前 main 快照 b7a70f30274f215dea9744dd535a6711b164ac3b 已包含 appServerBuckets、按 limitId 隔离、按当前模型匹配桶、陈旧桶处理及稀疏窗口合并。相关位置包括 apps/desktop/src/main/usageBroadcaster.ts、apps/desktop/src/renderer/hooks/useAccountUsage.ts 和 packages/maker-shared/src/codexUsageBuckets.ts。\n- 当前 main 的 RateLimitSnapshot 与相关合并逻辑尚未包含 normalModelSlug 或 supportsLunaReserve；这是因为 #4811 尚未合并，并非现有实现已经提供了 reserve 路由。\n- 既有桶选择逻辑在匹配不到当前模型时不会退回其他模型专属桶，而是优先选择稳定的通用桶；这为本 PR 的“reserve 必须明确属于所选模型”提供了正确的安全基线。\n- #4811 的方案将额度读取放在后台，按 provider/account 在 session 内缓存 30 秒并设置 5 秒上限，发送路径不等待冷查询；冷缓存时走普通 Luna，且不自动进行同轮 reserve 重试。这些边界有助于避免引入发送延迟或未经授权的路由。\n\n需要先处理的审查证据：PR #4811 当前讨论中的 Greptile review 指出，apps/desktop/src/main/usage/codexRateLimitReset.ts 附近的持久化/稀疏合并路径可能让一次省略 normalModelSlug 的合法 account/rateLimits/updated 覆盖已有模型绑定。后果是 matchCodexBucketForModel 无法再次选择 reserve 桶，额度展示回到“已耗尽”，并可能使后续发送无法使用已具备的 reserve。该意见与当前 main 已有的稀疏更新保护原则一致，因此应在批准前修复并用回归测试锁定。\n\n产品范围判断：这是新增的账户能力协商和 wire routing，不是单纯 bugfix；但当前方案没有新增可选模型、没有修改用户保存的模型、没有让 gateway/SSH 使用本机账户，也没有改变账号准入。可以继续审查，但产品确认不应替代代码审查、CI 或真实资格账户验收。\n\n相关记录：\n- #379：建立当前 Codex 用量按 limitId 分桶、按会话模型选桶的基础，直接影响本 PR 如何安全承载模型专属 reserve。\n- #4811：本次 Luna reserve 实现，仍为 open，尚未合并；其产品范围和待完成的真实账户验收是当前决策的直接依据。\n- #4227 与已合并 #4783：展示了仓库对跨模型协议适配采用请求侧、类型/字段边界明确且保留原始状态的处理原则；与 reserve 功能不是同一问题，因此仅作为实现边界的参考，不构成当前功能依赖。