feat: 段页式记忆流转、coldcontext 重命名与安全治理

记忆层：
- MemoryBlock 承载 FrameTS/PageSeq/PageKind/BlockRole/CallID
- coldcontext 归档与回填按完整页传递，工具调用参数和配对键不丢失
- 召回先估算总 token，超预算时按全局页相似度标记 inactive
- inactive 仅是 context 渲染期状态，不落盘、不进入 coldcontext，Prune 后重置
- Peek/确认/Remove 两阶段召回，失败保留冷上下文副本
- stablemem 记录 last_recalled_at，删块连带清理边

命名：
- internal/memory/document → internal/memory/coldcontext
- Doc/DocEvent/DocHit → ColdDoc/ColdEvent/ColdHit
- ContextToColdContext/RecentColdContexts/FindColdContexts
- 保留既有 JSON 标签、doc_ 文件前缀与 doc_count 状态键，兼容存量数据

安全治理：
- 工具策略门禁、安全配置、事件总线发布者身份与入站脱敏
- 声明式 SecurityAPI 与 QQ owner/guest profile
- 日志保留策略与相关 e2e/回归判据

验证：go build ./...、go vet ./...、go test ./...（62 包）；
生产副本 e2e：7013 块迁移后 ID/向量/指纹 0 变化、0 缺失。

third_party/homeagent-sdk/meta/meta.go

@@ -59,17 +59,31 @@ var (
 	// SDKName 是 SDK 名称。
 	SDKName = "HologramAgent SDK"
 
-	// SDKModule 是本 SDK 仓当前的 Go module path。
+	// SDKModule 是本 SDK 仓**当前**的 Go module path。
 	//
-	// ★ 2026-10-08 随托管地迁移：`gitcode.com/JianFeeeee/homeagent-sdk`
-	//   → `github.com/JianFeeeee/homeagentsdk`（仓库迁到 GitHub）。
+	// ★ 演进史（三次）：`gitcode.com/JianFeeeee/homeagent-sdk`
+	//   → `github.com/JianFeeeee/homeagentsdk`（迁到 GitHub）
+	//   → `github.com/JianFeeeee/hologramagentsdk`（与仓名统一，2026-10）
 	//
-	// ❗已有插件的 go.mod 里写的仍是旧路径（本机实测 qq/vanblog/mcquery/
-	//   fileproc/mail-bridge 五个插件工作区全是 gitcode.com/...）。
-	//   因此凡是要「识别 SDK 模块」的判定必须**两种都接受**
-	//   （见 hmapdev 的 sdkModulePath 助手），不能只认新名——
-	//   只认新名会让旧插件被当成「不是 SDK 模块」而静默走错分支。
-	SDKModule = "github.com/JianFeeeee/homeagentsdk"
+	// ★★ 本常量**必须与 go.mod 的 module 行逐字一致**（2026-10-29 实测缺陷）：
+	//
+	//   它此前停在中间名 `github.com/JianFeeeee/homeagentsdk`，而 go.mod 已
+	//   推进到 `...hologramagentsdk`。后果不是"显示错"，而是**模板工程编不出**：
+	//
+	//     · hmapdev 用本常量生成插件 go.mod 的 require/replace
+	//     · 而 SDK 内部（如 proc_main 运行时模板）引用的是 go.mod 的真名
+	//     ⇒ 两个模块名并存，`go build` 报
+	//       "no required module provides package .../sdk"
+	//     ⇒ 用户照提示 `go get` 只会**再拉一份** SDK，问题依旧。
+	//
+	//   因此凡改 module 名，必须同时改 go.mod 与本常量。判据见
+	//   `meta/meta_module_test.go`（钉住"与 go.mod 一致"，仅认改名后的新名）。
+	//
+	// ❗存量插件的 go.mod 里仍可能是更早的名字，所以「识别 SDK 模块」的判定
+	//   必须**所有历史名都接受**（见 hmapdev 的 sdkModuleNames）——
+	//   只认最新名会让旧插件被当成「不是 SDK 模块」而静默走错分支。
+	//   注意区分：**识别**要宽容，**生成**要精确（就是本常量）。
+	SDKModule = "github.com/JianFeeeee/hologramagentsdk"
 
 	// LegacySDKModule 是迁移前的 SDK module path，仍需被识别。
 	LegacySDKModule = "gitcode.com/JianFeeeee/homeagent-sdk"

third_party/homeagent-sdk/meta/meta_module_test.go

@@ -0,0 +1,65 @@
+package meta
+
+// SDKModule 与 go.mod 的一致性命中判据。
+//
+// ## 为什么必须有（2026-10-29 实测缺陷，代价是"模板工程开箱编不出"）
+//
+// 事实经过：
+//
+//	go.mod: module github.com/JianFeeeee/hologramagentsdk   ← 已改名
+//	meta.SDKModule = "github.com/JianFeeeee/homeagentsdk"   ← 停在中间名
+//
+// 两者不一致时，`hmapdev init` 生成的工程会**同时**出现两个模块名：
+//
+//	require github.com/JianFeeeee/homeagentsdk v1.4.0     （来自本常量）
+//	而 z_proc_gen.go 里 import .../hologramagentsdk/sdk   （来自 SDK 真实模块名）
+//
+// 结果 `hmapdev build` 报
+//
+//	no required module provides package github.com/JianFeeeee/hologramagentsdk/sdk
+//
+// 而用户照提示执行 `go get` 只会**再拉一份** SDK —— 两个模块名并存，
+// 问题原样保留。这类故障的恶劣之处：报错指向 import，真因在 meta.go。
+//
+// 所以本判据钉死"生成用的模块名 == go.mod 的模块名"。
+
+import (
+	"os"
+	"path/filepath"
+	"strings"
+	"testing"
+)
+
+func TestSDKModuleMatchesGoMod(t *testing.T) {
+	// meta/ 的上一级就是 SDK 仓根。
+	data, err := os.ReadFile(filepath.Join("..", "go.mod"))
+	if err != nil {
+		t.Fatalf("读 SDK go.mod 失败: %v", err)
+	}
+
+	var mod string
+	for _, line := range strings.Split(string(data), "\n") {
+		line = strings.TrimSpace(line)
+		if strings.HasPrefix(line, "module ") {
+			mod = strings.TrimSpace(line[len("module "):])
+			break
+		}
+	}
+	if mod == "" {
+		t.Fatal("SDK go.mod 里没有 module 行")
+	}
+
+	if SDKModule != mod {
+		t.Fatalf("★ meta.SDKModule 与 go.mod 不一致：\n"+
+			"  meta.SDKModule = %q\n"+
+			"  go.mod module  = %q\n"+
+			"两者不一致会让 hmapdev 生成的插件工程同时依赖两个 SDK 模块名，"+
+			"表现为 `no required module provides package .../sdk`。"+
+			"改 module 名时必须同时改这两处。", SDKModule, mod)
+	}
+
+	// 反向保护：LegacySDKModule 不得与当前名相同（否则"识别旧名"失去意义）。
+	if LegacySDKModule == SDKModule {
+		t.Fatal("LegacySDKModule 与 SDKModule 相同 —— 迁移前的名字应当不同")
+	}
+}

third_party/homeagent-sdk/sdk/plugin.go

@@ -612,6 +612,7 @@ type PluginSDK struct {
 	sett           SettingsAPI
 	social         SocialAPI
 	secrets        SecretsAPI
+	security       SecurityAPI
 	rawFiles       RawFilesAPI
 	events         EventSubscriber
 	plgMgr         PluginMgrAPI
@@ -715,6 +716,16 @@ func (s *PluginSDK) Secrets() SecretsAPI {
 	return s.secrets
 }
 
+// Security 返回**策略声明面**（插件声明安全档位；判定由内核执行）。
+//
+// ★ 只声明、不判定：本接口没有 CheckTool 之类的方法 —— 那属于内核。
+// 插件自判会让策略分散到每个插件、且插件崩溃即策略失效。
+func (s *PluginSDK) Security() SecurityAPI {
+	s.apiMu.RLock()
+	defer s.apiMu.RUnlock()
+	return s.security
+}
+
 func (s *PluginSDK) Social() SocialAPI {
 	s.apiMu.RLock()
 	defer s.apiMu.RUnlock()
@@ -933,6 +944,13 @@ func (s *PluginSDK) SetSecretsAPI(v SecretsAPI) {
 	s.apiMu.Unlock()
 }
 
+// SetSecurityAPI 由内核注入策略声明面的实现（插件不调用）。
+func (s *PluginSDK) SetSecurityAPI(v SecurityAPI) {
+	s.apiMu.Lock()
+	s.security = v
+	s.apiMu.Unlock()
+}
+
 func (s *PluginSDK) SetMemoryAPI(mem MemoryAPI) {
 	s.apiMu.Lock()
 	s.mem = mem

third_party/homeagent-sdk/sdk/security.go

@@ -0,0 +1,98 @@
+package sdk
+
+// SecurityAPI 是插件**声明**自身安全策略的接口。
+//
+// ## 为什么需要它（用户裁定 2026-10-26，2026-10-29 补齐实现）
+//
+// > 插件可以声明自身安全限制策略，并在插件自身 inputch 触发时携带参数
+// > 选择其中一种 —— 正好对应 QQ 插件内部 owner 与非 owner 的差别对待。
+//
+// > 这是可选参数，不声明安全策略则使用内核默认安全策略。
+//
+// ## 分工：插件只声明，内核只执行
+//
+//	插件：DeclareProfile / DeclareProfiles            （只声明，不判定）
+//	内核：CheckTool / CheckToolFor / ActivateProfile  （只执行，不信任插件）
+//
+// ★ 为什么判定必须在内核：插件崩溃或被重载时，声明不能跟着消失
+// （否则"挂掉插件"就是绕过策略的手段）；而且判定要与全局基线、主体策略
+// 走同一条链 —— 分散到各插件就是"被约束者自己决定约束"，
+// 本仓已有实测教训（QQ 的 beforeToolcall 自己判身份/白名单/硬私有，
+// 结果每个插件各写一套、拒绝语义散落、插件崩了策略就没了）。
+//
+// ## 声明 vs 全局基线：两层，职责不重叠
+//
+//	① 全局基线（部署方配置 core.security.*）：不受插件影响，防"插件自己放水"
+//	② 档位（本接口）：单次请求的**收窄**
+//
+// 档位**只能收窄**：内核的判定顺序是「全局 deny → 档位 deny → 主体 deny
+// → 全局 allow → 档位 allow」，全局黑名单永远先判，档位绕不过去。
+//
+// ## 缺省语义（重要）
+//
+//	不声明 / 不传 = 不使用档位，一切判定沿用内核默认策略
+//
+// 也就是说这是**可选**能力：不用的插件行为与之前完全一致。
+// 而一旦传了**未声明**的档位名，内核会**报错**而不是静默回落 ——
+// 拼错档位名却默默用默认策略是安全事故的经典形态。
+//
+// ## 典型用法（QQ 插件）
+//
+//	// Start 阶段：声明两个档位（只声明，不判定）
+//	s.Security().DeclareProfiles([]SecurityProfile{
+//	    {Name: "qq.owner", Owner: "qq", AllowTools: []string{"*"}},
+//	    {Name: "qq.guest", Owner: "qq",
+//	     DenyTools: []string{"cmd_*", "files_write"},
+//	     SensitiveWords: []string{"内部代号"}},
+//	})
+//
+//	// 注入阶段：按发送者身份选择档位
+//	s.InjectTextOpts(source, channel, text, sdk.InjectOptions{
+//	    SecurityProfile: "qq.guest",
+//	})
+//
+// ## 名字约束
+//
+// 档位名必须是 `<owner>.<档位>`，其中 owner 等于插件名。这条在内核侧
+// 强制（否则插件 A 能声明 `qq.owner` 并夺走插件 B 的档位语义）。
+type SecurityAPI interface {
+	// DeclareProfile 声明一个命名档位。同名重复声明会覆盖（同一 owner
+	// 只能覆盖自己的档位，不能覆盖别人的）。
+	//
+	// 返回 error 的情形：
+	//   · 名字不符合 `<owner>.<档位>` 形式
+	//   · owner 与本插件名不一致（试图声明别人的档位）
+	//   · 安全模块未启用（此时没有可声明的策略容器）
+	DeclareProfile(p SecurityProfile) error
+
+	// DeclareProfiles 批量声明（任一失败即整体失败，便于早失败）。
+	//
+	// 为什么提供批量版：QQ 这类插件有 3~4 个档位，逐个判断 error 会让
+	// Start 里堆满重复代码；而"声明到一半失败"是更难排查的状态。
+	DeclareProfiles(ps []SecurityProfile) error
+}
+
+// SecurityProfile 是一个**命名安全档位**的声明。
+//
+// 与 ToolPolicy 类配置的区别：档位是**运行时可选**的（按 inputch 输入
+// 携带的参数选择），不是全局生效的。
+type SecurityProfile struct {
+	// Name 是档位名，必须形如 `<owner>.<档位>`（如 "qq.guest"）。
+	Name string
+	// Owner 是声明者（插件名）。与 Name 的前缀必须一致。
+	Owner string
+
+	// AllowTools / DenyTools 是本档位下的工具白/黑名单（支持尾部 `*` 前缀）。
+	//
+	// 语义（与全局策略一致，且**只能收窄**）：
+	//   · DenyTools 命中 ⇒ 拒绝（且它叠加在全局黑名单之上，不能反向放行）
+	//   · AllowTools 非空且未命中 ⇒ 拒绝
+	//   · 两者都空 ⇒ 本档位不额外限制
+	AllowTools []string
+	DenyTools  []string
+
+	// SensitiveWords 是本档位额外追加的敏感词（在全局敏感词之上追加）。
+	//
+	// 用途：某些词只在特定身份下才敏感（如非所有者对话时不该看到内部代号）。
+	SensitiveWords []string
+}