feat(plugins): add scoped prompt and host context services

[xxhZs]

Problem

Trusted Host-side plugins need two related capabilities that currently require ad-hoc integration: contribute model instructions/context for the active Session, and use bounded Host services under the same Plugin Fiber and Session authority.

The required lifecycle is: activate a contribution in one Plugin scope, resolve only the contributions visible to the current Session, re-evaluate dynamic input before each logical model step, and remove or restore the contribution atomically on unload, replacement, or rollback.

Summary

• add Fiber-owned ctx.systemPrompt sections, complete overrides, variables, and dynamic context contributions
• inherit Profile contributions into Session scopes with deterministic ordering and exact-name shadowing
• keep the Host base prompt snapshot stable while re-evaluating Plugin contributions before every logical model step
• record effective contribution revisions in RequestComposition and expose bounded Host-side inspection
• add scoped Host context services for agents, questions and approvals, session queries, skills, goals, commands, LSP, shell and environment, filesystem, attachments, Web access, metered LLM calls, settings, storage, credentials, and authorization
• bind every invocation-sensitive service to the current Session/Turn/Tool authority, preserve cancellation and permission ceilings, and fail closed when that authority is absent
• publish and retire service registrations with the existing package/Entry/Fiber lifecycle so failed replacement restores the previous generation without leaking cross-Session state

These services share the same scope registry, lifecycle publication, and Host binding path as dynamic prompt contributions, so this PR reviews that common context boundary as one unit.

Out of scope

• Session execution backends and executionBackend
• replacing the Maka Agent Loop with a Plugin executor
• Desktop UI contribution surfaces

The Session Executor work previously present on this branch has been removed and will be proposed separately with its own execution, stop, recovery, and lifecycle contract.

Verification

• npm run typecheck --workspace @maka/runtime
• npm run typecheck --workspace @maka/runtime-host
• npm run build --workspace @maka/core
• npm run build --workspace @maka/storage
• npm run build --workspace @maka/runtime
• npm run build --workspace @maka/runtime-host
• 155 focused Runtime, Composer, scoped-service, data-runtime, Plugin Platform, and protocol tests

[likun666661]

从问题定义和奥卡姆剃刀的角度看，动态 prompt 主线成立，但当前 PR 的范围已经明显超过标题和 Summary。

建议收敛的问题定义

让受信任插件为当前会话贡献模型指令或上下文；状态变化在下一次逻辑模型步骤生效，且不串会话、不残留、不改写历史。

对应的因果链是：插件注册贡献 → 选择当前 Session 可见的贡献 → 每个逻辑模型步骤重新求值 → 组装请求并记录来源版本。

当前实现把按 sessionId + turnId 缓存的 Host 基础提示词与每步重新求值的插件贡献分开，确实能让工具执行后的插件状态变化进入下一次模型调用。作用域隔离、确定性排序、卸载清理、失败替换回滚，以及 source revision / inspection，都是应保留的正确性和诊断边界。这里稳定的是 Host 基线，并非完整 system prompt。

哪些复杂度还需要需求证据

• variable() 与模板插值：text(context) 回调已经可以生成动态文本。若没有声明式模板或跨插件共享变量的实际消费者，可以先推迟模板机制，避免同时维护两套动态文本能力。
• complete 全量替换：这不是追加上下文，而是替换 Host 基础提示词及其他非 complete sections，需要独立说明消费者、预期语义和必须保留的约束。
• agent、审批、文件/Shell、附件、Web、LLM、设置/存储/凭据等服务：各自可能有价值，但不是上述动态 prompt 闭环的前提。
• session executor / executionBackend：这是另一类需求，即在保留 Maka 会话和事件契约的前提下替换执行后端，涉及持久化、停止、恢复和热重载，应独立定义和评审。

建议

建议按三个可独立验收的目标拆分：

1. 模型输入扩展：用一个真实插件场景验证“工具修改状态后，下一步模型看到新状态”，并验证跨会话隔离、卸载/回滚和历史不累积。
2. Host 能力开放：按实际插件消费者逐项引入 scoped services。
3. 会话执行器扩展：独立验证后端选择、事件转换、停止、恢复与生命周期。

目前在仓库中查到的新 prompt 注册调用主要在测试里，尚未找到非测试业务消费者；这不排除外部已有需求，但建议补充具体场景及验收标准。若这些能力确实必须一起交付，也需要说明不可拆分的依赖，并更新标题和 Summary。

核心意见不是为了减少行数而删掉安全边界，而是：“插件状态能正确进入下一次模型请求”是清晰的问题；“补齐插件平台所有能力”不是它的最小解。

以上基于 3ce03f4 的代码与相关测试阅读，未运行构建或测试。