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.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed exact head: 0db3a5116fe04461bbe0a01f3498a28da5bf676e

This review addresses the blocking findings from review 5296107647 on head ec6649213f8459f3629262f595f8dac591901b66.

动机

两个 Lark listener 可能在 delivery receipt 写入前各自生成并发送管家答案；设置页也把管家的模型与运行环境埋在混合能力列表里。上一轮 review 判定设计与局部回归成立，但当前 head 与主干冲突、且最低 Node lane 有 SQLite deferred-lease 失败，因此不可合并。

改动思路

保持原方向：对已验证为 turn-authorized 的 manager source message 使用既有跨进程文件锁，锁内继续走原 Inbox、回复 receipt 与 ACK；context-only 消息不获得答复权限。设置页只重排既有 machine capability 编辑器，预览、应用与读回仍由原配置 API 负责。本次工作是把分支同步到最新 main 并重新取得新 head 的必需证据。

具体改动

• loopx/extensions/lark/goal_topic_runtime.py：按合法 message ID 单飞，锁覆盖生成答案到 ACK 的整个 effect；主干侧该文件的后续改动已保留。
• workspace-settings-page.tsx 与 personal-workspace.css：把本分支的分组侧边栏与主干新增的自动化节奏页合并为一套导航——管家、模型 Provider、能力中心与 Goal 级能力/节奏同组，Lark、外观、语言为工作区组；主干新增的标题与 Goal 目标徽标样式保留。
• automation-cadence.mjs：本改动把机器设置入口重命名为“能力中心”，因此该打包浏览器场景改为点击新名称；场景清单同时保留主干的 automation-cadence 与本分支的 steward-model-settings。
• 生成的 loopx/web/chat 产物延续主干删除（不进 Git），并按前端交付策略在合并后的源码上重新构建与校验 bundle。

对主干的风险

上一轮的两个阻塞项已消除：分支与最新 main 的冲突已在上述文件中解决且工作树干净；最低 Node lane 不再出现 SQLite deferred-lease 失败——在仓库声明的最低版本 Node 22.22.3 下 deferred_hard_lease_lifecycle 8/8 通过，此前失败所依赖的运行时基线修复已由 #4960 合入主干。单飞的 960 秒锁等待仍是需要继续观察的运营风险：它会延迟同一消息的重复事件处理，但不会因此推断重复发送。本地验证：Lark runtime 67/67，最低 Node lane 的 SQLite 相关文件 332 项中 331 通过，唯一失败是 sqlite_capacity 容量演练，它在未改动的 main 上以同名复现，属宿主环境而非本改动。

我的整体评价

设计边界成立：复用既有 manager authority、文件锁与配置编辑器，没有新权限或持久状态；同步主干后新 exact head 的必需证据齐全。该改动属前端/产品与 Lark 运行时表面，按仓库策略通常应由维护者合并，这里依仓库所有者指示作自合并并公开上述边界与证据。

Validation on this head: Lark goal-topic runtime 67 passed; minimum-Node (22.22.3) SQLite authority/admission/deferred-lease/bounded-profile/migration files 331 passed with one pre-existing sqlite_capacity host failure that reproduces on main; dashboard tsc --noEmit passed; chat bundle rebuilt and verify --source passed; packaged browser smoke passed all 11 scenarios including steward model settings and automation cadence; loopx canary premerge --from-git-diff selected smokes and the public-boundary scan passed; change-quality receipt cqr_d9e8f5fb7d42ce322283 valid. Remote CI was not awaited (wait_for_ci=false).

English verdict: APPROVE - head 0db3a5116fe04461bbe0a01f3498a28da5bf676e; the branch now merges cleanly with main, the minimum-Node SQLite deferred-lease failures are gone after the #4960 runtime baseline landed, and the duplicated-reply single-flight plus the regrouped steward settings pass their Lark, typecheck, bundle and packaged browser gates.

[huangruiteng]

Merge decision (author-owned PR; admin bypass)

Requested change: addressed. Both blocking items from review 5296107647 are resolved, and exact-head review 5302782912 is published on the merged head.

• Validated exact head: 0db3a5116fe04461bbe0a01f3498a28da5bf676e
• Merge commit: cc60e8b3ccf6f58f14f0d42a5b66c77a56d9e17d
• Tree check: git diff --stat <head> <merge-commit> is empty
• Readiness gate: loopx pr-review --check-merge-readiness 4936@<head> returned ready=true with no blocking reasons (wait_for_ci=false)
• Change-quality receipt: cqr_d9e8f5fb7d42ce322283 (valid, exact current base and diff)

Repair content: the branch was synced to latest main (the stack had drifted by 272 commits, then seven more before merge). Conflicts were resolved by combining rather than choosing: workspace-settings-page.tsx now carries one grouped sidebar that keeps this branch's steward/model/capability grouping together with upstream's automation-cadence page, and personal-workspace.css keeps upstream's settings heading and Goal target styles alongside the grouped-tab styles. Because this change renames the machine entry to the capability center, the upstream automation-cadence browser scenario was updated to the new label, and the scenario catalog keeps both upstream's cadence scenario and this branch's steward model settings scenario. Generated loopx/web/chat output stayed deleted per docs/development/frontend-delivery.md and the bundle was rebuilt from the merged source. Both merge commits carry DCO trailers.

Validation on this head: Lark goal-topic runtime 67 passed (includes single-flight duplicate-reply coverage); minimum-Node lane at the declared floor (Node 22.22.3) — SQLite authority, admission, deferred-lease, bounded-profile and migration files 331 passed; dashboard tsc --noEmit passed; chat bundle rebuilt and verify --source passed; packaged browser smoke passed all 11 scenarios, including steward model settings and automation cadence.

Attributed or pre-existing failures: one sqlite_capacity capacity rehearsal fails identically on unmodified main (host environment, not this change); the four minimum-Node SQLite deferred-lease failures reported earlier are gone now that the #4960 runtime baseline is on main. The packaged smoke spawns its own interpreter and would otherwise use the host python3 3.9, so it ran with an explicit supported interpreter.

Carried limits: the 960-second lock wait delays handling of a repeated event for the same message, which stays an operational watch item and does not by itself prove duplicate delivery; real Lark dual-listener click-through was not reproduced here. This touches the Lark runtime and frontend/product surfaces, which repository policy normally leaves to the maintainer; it is self-merged here on explicit owner instruction, with the evidence above published.