Fix duplicate steward replies and focus steward settings

[huangruiteng]

A single Lark message could receive two full steward answers when concurrent listeners both saw an empty delivery receipt. The Lark manager route now serializes answer generation, provider reply/readback, and inbox ACK by source message; a concurrent retry recovers the acknowledged result.

Steward settings now have a first-level destination with just Model and executor and Runtime. The separate Capability Center / 能力中心 lists other machine capabilities, while Goal-only controls remain in Goal settings. The same machine configuration API provides preview, apply, rollback and readback. Model and reasoning-effort selection remains available, and the UI explains that saving a machine default does not silently switch an existing session.

The semantic handoff RFC and roadmap define how a future steward request selects an authorized, active, context-relevant Agent and returns a verified result to the original frontend or Lark conversation. This PR does not claim that automatic context-affine dispatch is implemented.

Validation on the final head: dashboard typecheck and packaged build, all 10 packaged workspace browser scenarios, and 65 Lark manager-routing tests passed. The repeat build was deterministic; the retained asset manifest points to the current and actual prior bundle. The public/private boundary scan and all 19 selected premerge checks passed with no manual holds. Exact-diff change-quality receipt cqr_4bbd939cd2ef4d5ace43 is valid. Earlier broader validation covered 118 focused Python tests. A targeted mypy diagnostic was non-passing because the repository currently reports thousands of existing typing errors; it was not used as the acceptance oracle for this change.

Entry points: Lark manager messages and packaged frontend settings. Existing manager sessions keep their prior allocation until a new or compatible resumed session is opened. No Goal permission, authority, or private state is included in this PR. Future-facing pass: the existing machine configuration and Lark request/outbox contracts were reused, without a second configuration store or dispatcher.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Exact head: ec66492

动机

两个 Lark listener 可能在 delivery receipt 写入前分别生成并发送管家答案；设置页也把管家的模型/运行环境埋在混合能力列表里。这两个已存在的用户入口是合理的修复对象。

改动思路

对已验证为 turn-authorized 的 manager source message 使用现有跨进程文件锁，锁内继续走原 Inbox、回复 receipt 与 ACK；context-only 消息不获得答复权限。桌面端只重排现有 machine capability 编辑器，预览、应用和读回仍由原配置 API 负责。

具体改动

关键代码讲解

• process_lark_goal_topic_event（loopx/extensions/lark/goal_topic_runtime.py:841）按合法 message ID 单飞，覆盖生成答案到 ACK 的整个 effect。
• MachineConfigurationSettings（apps/presentation/dashboard/src/features/personal-workspace/machine-configuration-settings.tsx:104）把模型/执行器和 Runtime 单列到管家设置，未另造配置写入路径。
• WorkspaceSettingsPage（apps/presentation/dashboard/src/features/personal-workspace/workspace-settings-page.tsx:67）分组导航，保留 Goal-only 能力的上下文约束。

对主干的风险

本地 test_lark_goal_topic_runtime.py 65/65 通过（含并发同消息仅回复一次）；exact-head dashboard-acceptance 也通过。但当前 PR 显示 CONFLICTING，且 exact-head node-minimum-compatibility 有 4 个 SQLite deferred-lease 失败，merge-gate 为红。这是合并集成阻塞，不能拿本地 Lark/UI 通过代替。请同步当前 main、解决冲突并重跑 required checks；最低 Node lane 还需等待 #4960 所提的运行时基线修复（或等效修复），当前 main 仍是 22.18.0。现有 960 秒锁等待会延迟同消息重复事件处理，属需继续观察的运营风险，不能据此推断重复发送。

语义与 CI 对齐

复用既有 manager authority / machine-configuration 语义，没有新权限或持久状态。当前缺的是新 head 对最新主干的 CI 证据，而非把规则改成“指导性建议”。

我的整体评价

设计边界与局部回归测试是成立的，相关未来向整理也已通过复用文件锁和配置编辑器完成，无需再加抽象；但当前 head 不可合并。同步主干后请在新 exact head重跑 65 个 Lark 测试、打包设置场景及 required CI，再请求复审。

English verdict: REQUEST_CHANGES - current head conflicts with main and required minimum-Node CI is failing; sync and requalify the new exact head.