feat(tui): publish MCP tools to remote Runtime Hosts

[me2seeks]

Summary

Publish the TUI's MCP tools to a selected remote Runtime Host without widening the terminal Client credential or moving MCP ownership into the Host.

• Store the capability-provider credential outside profile metadata, arguments, and conversation data. Bind it to the exact remote profile target and the terminal Client identity, separately from the terminal access credential.
• Run one profile-bound publication companion for remote TUI profiles. It reuses the existing reconnecting connection while the TUI MCP controller remains the sole MCP manager, configuration owner, and publication queue.
• Let /mcp set or remove the provider credential and distinguish missing, rejected, target-mismatched, and reconnecting states without displaying the secret.
• Retire the companion deterministically on credential rotation, profile removal, or TUI shutdown, including an in-flight initial connection and a libp2p peer client.
• Exercise the real authenticated WebSocket path with two associated providers, exact-root rejection, Host restart and republish, credential revocation, and MCP stdio child cleanup.

Refs #3838
Depends on #4187

Review focus

The terminal credential still cannot publish Client Capabilities. A Host owner explicitly issues a separate provider credential associated with the terminal Client, and the TUI stores that secret in the local credential store for the exact profile target.

This PR does not add another McpClientManager, configuration store, publication queue, retry timer, or Host-side MCP manager. The companion owns only its credential-bound connection. Closing that connection retires its Host registration; the existing TUI controller remains the only authority that starts MCP servers and replaces or unregisters the published tool snapshot.

Provider ambiguity remains fail-closed at the Host selection boundary introduced by #4187. The TUI does not invent a second provider-selection or status authority.

Verification

• npm run build:test
• npm --workspace @maka/runtime-host run test:dist — 1,382 passed, 9 skipped
• npm --workspace maka-agent run test:dist — 638 passed
• npm run typecheck
• npm run lint — 2,942 files checked, no findings
• npm run format:check — 1,767 files checked
• npm run check:asf-headers
• git diff --check feat/3838-mcp-provider-association...HEAD

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex traced the credential, Runtime Host connection, TUI MCP publication, and shutdown boundaries; implemented the remote publication companion and /mcp credential flow; added unit and real-network lifecycle coverage; and performed architecture and simplification reviews. All four commits carry a Generated-by: Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Thanks for preserving one TUI MCP manager and publication queue while adding only a credential-bound remote companion. That is the right architecture direction and avoids moving MCP ownership into Runtime Host.

I reviewed exact head 3f1e02758a6a097fe998b09470e01007d36c4f3d. The PR body contains no screenshots or terminal recording for the new /mcp credential and publication states. Please attach the missing, rejected, target-mismatched, reconnecting, and published flows, including the credential-entry screen, without exposing a real secret.

This stacked PR cannot merge until the P1 in its #4187 base is fixed: an unbound remote-owner credential can claim another Client ID and obtain the associated provider. #4200 does not introduce that primitive, but it makes the affected provider a real TUI MCP publication, so the stack inherits the trust-boundary failure.

I found three additional P2 issues:

1. Removing a profile from another process does not retire the running companion. The target retains the old profile and credential, remains registered, and can republish after reconnect. Profile removal needs an explicit lifecycle fence that closes publication.
2. A permanent libp2p reconnect failure or credential revocation updates availability but does not close the peer client. The native endpoint and relay resources can remain until credential replacement or TUI exit.
3. The provider credential is entered through a normal visible Editor, despite the PR statement that the secret is not displayed. Please use a masked secret-input treatment and verify that rendered history and diagnostics never expose it.

The remote integration test verifies publication, restart, revocation, root mismatch, and child cleanup, but never binds a real Session and invokes the published MCP tool. It also mocks away the production target-and-owner credential key. Please add at least one production-composition path from TUI context → Session provider selection → actual MCP invocation using the real credential store boundary.

There are currently no hosted checks for this exact head.

Review analysis was assisted by Codex and independent @reviewer agents. Astro-Han verified the exact head, stacked authority boundary, profile and libp2p lifecycles, credential presentation, integration coverage, and severity judgment, and owns this review.

中文对照

谢谢你保留唯一的 TUI MCP manager 和 publication queue，只增加 credential-bound remote companion。这个架构方向正确，也避免把 MCP ownership 移进 Runtime Host。

我审查了精确 head 3f1e02758a6a097fe998b09470e01007d36c4f3d。PR 正文没有新 /mcp credential 和 publication 状态的截图或终端录屏。请补充 missing、rejected、target-mismatched、reconnecting 和 published 流程，包括 credential 输入界面，但不要暴露真实 secret。

这个 stacked PR 必须等待 base #4187 的 P1 修复：未绑定的 remote-owner credential 可以冒用另一个 Client ID 并获得对应 provider。#4200 没有新增这条 trust primitive，但会让受影响 provider 成为真实 TUI MCP publication，因此整组继承该信任边界问题。

还有三个 P2：

1. 另一个进程删除 profile 时，正在运行的 companion 不会退出。target 仍保留旧 profile 和 credential，继续注册，并能在 reconnect 后重新发布。profile removal 需要明确的 lifecycle fence 来关闭 publication。
2. libp2p 永久重连失败或 credential 被撤销时，只更新 availability，没有关闭 peer client；native endpoint 和 relay 资源可能保留到 credential replacement 或 TUI 退出。
3. provider credential 使用普通可见 Editor 输入，与 PR 所说的 secret 不显示不符。请使用 masked secret input，并确认渲染历史和 diagnostics 不会泄露。

remote integration test 验证了 publication、restart、revocation、root mismatch 和 child cleanup，但没有绑定真实 Session 并调用已发布的 MCP tool；它也通过 mock 绕开了生产 target-and-owner credential key。请至少补一条真实 production composition：TUI context → Session provider selection → 实际 MCP invocation，并经过真实 credential store boundary。

当前 exact head 没有 hosted checks。

本次审查分析由 Codex 和独立的 @reviewer 子代理协助；Astro-Han 核验了精确 head、stacked authority boundary、profile 与 libp2p lifecycle、credential presentation、integration coverage 和问题分级，并对本次 Review 负责。