feat: add host active memorization instructions

[MrXnneHang]

📝 Pull Request Summary

让 host agent 在用户要求记住内容，或已完成任务产生长期偏好、决策和可复用流程时，按需读取共享指南并执行主动 memorize。

这是供分层评审的 stack 上层，基于 #700，与 xnne-bot 的 #699 使用相同 head。最终合入由 #699 承接；本 PR 用于评审，请勿直接合入。 当前相对底层仅 1 个提交、7 个文件。

---

✅ What does this PR do?

• 给各 host 的 managed instruction 增加简短的主动 memorize 触发指引。
• 新增离线命令 memu memorize instructions，打印随包分发的完整操作指南。
• 复用 developer run 契约，覆盖真实消息输入、串行 evolve、commit、失败保留与 discard。
• 通过现有 install-instruction / remove-instruction 分发和移除指引。

---

🤔 Why is this change needed?

Host agent 需要在已完成交流中保存值得保留的内容，共享按需指南让所有 host 使用一致的执行契约。

原实现与讨论：#699；底层生命周期：#700（对应 #698）。

• 触发场景、显式话术、pi skill 入口建议与实际运行结果
• 流程压缩优先级与建议的 memory-only 流程

直接接收模型提炼候选、/skill:memu-memorize 入口与按类型 evolve 均为后续能力；类型选择由 #697 跟踪。

---

🔍 Type of Change

• Bug fix
• New feature
• Documentation update
• Refactor / cleanup
• Other (please explain)

---

✅ PR Quality Checklist

• PR title follows an allowed format (for example feat:, fix:, docs:, memory base:)
• Changes are limited in scope and easy to review
• Documentation updated where applicable
• No breaking changes (or clearly documented)
• Related issues or discussions linked

沿用 #699 对相同提交的验证：710 passed、7 skipped；mypy / pre-commit 通过；覆盖 9 个 host 的安装、重复安装与卸载，wheel 包含完整指南。

另在 pi 中完成一次用户显式请求的真实 Cloud prepare → evolve → commit → 回读验证，产出 1 条 memory，run 已自动清理。尚未验证所有 host / 模型的自主触发稳定性。

本次仅建立评审 stack，没有新增代码改动。

---

📌 Optional

• Screenshots or examples added (if applicable)
• Edge cases considered
• Follow-up tasks mentioned

[xnne-bot]

补充主动 memorize 的流程压缩顺序，作为后续优化建议。

这次真实运行产出为 1 条 memory、0 条 skill、0 条 resource。对于“保存刚才确定的设计”这种明确的 memory 请求，skill job 检查后没有新增产物，resource 验证结果也为 0；完整流程能工作，但有可省去的执行成本。

优先级	可压缩部分	建议
1	固定执行全部 memory / skill / resource jobs	先做 #697 的按类型 evolve。明确保存 memory 时，只执行 memory evolve；only skill 与 resource 的关系也需明确。选择应贯穿 prepare、run marker 和 commit 范围。
2	模型把已理解的上下文重新组织成对话，再读回来提炼	支持明确标注的“模型提炼候选”输入，让模型直接提交候选结论；保留其来源语义，不能冒充用户原话。候选仍经过 evolve 与已有记忆比较。
3	简单请求仍拆成多个指令文件并逐个读取	memory-only 可以返回一份完整 handoff，减少 job 拆分及读取次数。执行目标与 job 粒度分开设计。
4	准备与本次目标无关的工作区内容	按所选类型进行镜像和快照，先减少无关 skill 文件的写入与检查。仅在客户端过滤不会减少后端列表响应流量；服务端查询优化可另行评估。
5	message-only 输入生成两个相同的 JSONL	按执行目标只生成必要投影。优先减少 agent 的无效工作，再优化文件写入。
6	同一会话重复读取相同完整指南	已加载且版本未变化时复用指南，减少重复上下文与工具调用。
验证开销	每次 commit 后再全量回读	本次回读用于验证真实持久化；正常成功路径通常可依赖 commit 响应，按需再做回读检查。

应保留的步骤：输入校验、与已有记忆的比较/去重、明确的 commit 边界，以及失败保留和恢复。模型理解当前上下文，并不意味着它知道后端已经保存了什么。

建议的主动 memory 流程：

模型从已完成上下文提炼候选
  → prepare 独立 run，准备现有 memory
  → 一次 memory evolve：比较、去重、修改
  → commit
  → 自动清理该 run

以上是基于本次产出的优先级判断，尚未做逐阶段耗时测量，也不是当前已实现的简化路径。本 PR 继续聚焦 host 指令分发与触发入口。

[MrXnneHang]

1. memorize api 需要支持单独的 skill、memory、resource evolve。 加上审查 resource evolve 是否必要。
2. 无需优化、提炼，应该只是把模型 "上下文" 中的原文弄上去就可以了。
3. 需要主动 memorize 是否还有必要搞 job - session 分离
4. 关联 2. 3.
5. 关联 2.3.4
6. 具体是为什么会再次读取指南？ 是因为一个上下文，多次 memorize 时会不断重读指南还是别的什么？定时 memorize 有没有这个问题？
7. 我认为默认无需重读，只要知道提交成功与否就可以了。

[xnne-bot]

逐项回应：

1. 类型选择与 resource 必要性：当前固定跑 memory + skill + resource，resource 的路径由 skill job 收集。建议三者可独立选择；memory/skill 不默认附带 resource。独立 resource 需要先解耦路径收集，其价值看是否需要以后检索任务产出的文件。这次 0 个 resource 只能说明这次讨论不需要它。
2. 输入：直接选取模型当前可访问上下文中的真实原文，保留角色和顺序，清理敏感信息；现有 canonical JSON 可以承载。提炼交给 evolve，输入阶段无需增加摘要处理。
3. job–session 分离：当前没有强制另开模型会话，可以由当前 agent 完成。指令与原文应有清楚的边界，但主动流程可合并为一份执行指引，不必拆成多个 job 文件。run 内保留输入，方便中断恢复或转交执行。
4. 工作区准备：跟随 2、3 和所选类型，只准备本次需要的镜像、快照和指引，不必单独设计一套优化机制。
5. 重复 JSONL：当前为 memory/skill 固定生成两份投影，只有消息时两份内容相同。随执行目标生成所需输入即可，和 2、3、4 一起调整。
6. 为什么重读指南：是同一上下文多次主动 memorize 时，常驻指令每次都要求运行 memu memorize instructions；我刚才确实重复读取了。指南仍完整在上下文中时应复用，新会话或上下文丢失时再加载。定时流程不调用这个主动指南入口；pi 定时运行使用独立上下文，需要加载调度指令和本次 jobs。另外，两条 prepare 路径都会尝试拉取 job 模板，这是另一项网络开销，应与模型重读区分。
7. 提交后回读：同意默认以 commit 结果确认完成。之前的 Cloud 回读是实测验证，不是指南要求的常规步骤；清理失败则报告具体状态，不重复提交。

后续优先做类型选择，再一起简化主动流程的输入与执行指引，并复用已加载指南。