feat(security): 插件按工具声明内容策略 + 目录名统一

## 一、插件声明层（用户裁定）

> 「敏感词策略也应该是插件声明啊，每个插件声明自己轮次以及自己工具的
>   敏感词策略」

SecurityProfile 新增两个字段：

  ToolSensitiveWords map[string][]string  // key=工具名模式(尾 *)，value=词表
  DetectInjection    bool                 // 开启内核内置注入迹象识别

语义是**追加不覆盖**：整轮 SensitiveWords 仍然生效。
取宽不取窄的理由：当前处置是 B 档（标记+警示，不阻断），
多标一条只是多一句警示，漏标则是安全缺口。

## 二、修掉我自己造的「莲藕式分层」

前一版把 *security.Round 从 runInputTask 一路搬到工具链
（prepareInputTask(evt, round) → TaskFrame.SecRound →
executeToolCallOutcomeWithRound），并在 rtchild 里另补一条。

那是把**分层策略实现成跨层传参**：每多一条工具执行路径就要求调用方
多传一次句柄。profileActivator 的设计注释早就写明了正路：

> 工具调用发生在 LLM 决定之后，此时插件已不在调用栈上。
> 唯一可靠的传递方式是**内核在输入进来时记住**，在该轮的工具判定里使用。

改为 security 自取：

  Runtime.ScanContentForAgent(agentID, isChild, ins, text)
    → ForAgent(agentID, isChild)   // per-agent 视图，天然不串档
    → EffectiveProfile()           // session > longtime
    → 合并 全局词表 + 档位词表 + 工具词表 + DetectInjection

core 只递交**事实**（我是谁 / 哪个工具 / 什么文本），不认识 Round。
与 CheckToolForAgent 同一套身份推断，不引入第二个入口语义。
TaskFrame.SecRound / executeToolCallOutcomeWithRound 全部撤除。

## 三、目录名统一

third_party/homeagent-sdk → third_party/hologramagentsdk

module 与远端仓早已是 hologramagentsdk，只剩物理目录是遗留名。
同步改了 go.mod replace、构建/打包/部署脚本、5 处测试里的分段路径。
注意：这里改的是**主仓 vendored 的 SDK 源码路径**，example/ 由 SDK
独立仓自己跟踪，主仓不涉及。

## 判据

TestToolSensitiveWordsAppendOnlyForThatTool   词表只对目标工具生效 + 追加语义
TestToolSensitiveWordsUseAgentScope           security 按 agent scope 自取生效
（变异验证：删掉 ForAgent 查询 → 红）

## 验证

	go build ./...                 → 0
	go vet ./...                   → 0
	go test ./... -count=1 -race   → 62 ok / 0 FAIL / 0 DATA RACE
	gofmt -l internal/             → 干净

docs/zh/legacy-issues.md

@@ -142,7 +142,7 @@ PluginContext（独立身份，共享管道）。
 
 **证据**：
 - `internal/plugin/proc/plugin.go:134`（`Spawn`，逐插件起进程）
-- manifest 无 `worker_group` 键（`third_party/homeagent-sdk/example/a2a/plugin.json`
+- manifest 无 `worker_group` 键（`third_party/hologramagentsdk/example/a2a/plugin.json`
   的键集合为 `author/description/entry/name/name_en/name_zh/platforms/tags/version`）
 
 **子任务**：
@@ -196,7 +196,7 @@ PluginContext（独立身份，共享管道）。
 **证据**：
 - `internal/plugin/proc/capability.go:149-150`（subscribe/unsubscribe 已授权）
 - `internal/plugin/proc/corehandler.go:46-58`（`EvtRingSubscriber` 接口）
-- `third_party/homeagent-sdk/example/` 下 21 个 example 中无事件订阅样例
+- `third_party/hologramagentsdk/example/` 下 21 个 example 中无事件订阅样例
 
 **子任务**：
 1. 写一个订阅 `stage` / `tool_call` 事件的 example 插件，跑真实负载
@@ -503,7 +503,7 @@ SDK 的 `remotedevice/src/ha_json.c`（368 行）经实测有**三个对协议
 1. **C 实现放哪里 → 留在主仓 `csrc/`。** 用户澄清：C 实现本来就是**替换**内核的
    Go 实现（`csrc/` 是唯一权威源，Go 侧符号链接 + cgo 绑定，`codec_pure.go`
    已降级为黄金对照的规格基准）。SDK 从头到尾**未被触碰**
-   （`git diff main -- third_party/homeagent-sdk/sdk/` = 0 行）。
+   （`git diff main -- third_party/hologramagentsdk/sdk/` = 0 行）。
    所谓「进 SDK」只对**跨端复用**（鸿蒙/嵌入式/C SDK 也想调同一份实现）才有意义，
    而它们并不调用内核编解码层 ⇒ 该问题**关闭**，不作为待办。
 2. **`ha_json.c` 复用还是新写 → 新写。** 见上（三个致命缺陷 + 架构正交）。
@@ -515,7 +515,7 @@ SDK 的 `remotedevice/src/ha_json.c`（368 行）经实测有**三个对协议
 `docs/zh/c-core/llm-orchestration-c.md`）。基础设施门禁已建成（见上）。
 下阶段扩大前，**三处需 jianf 拍板**（建议已附，见上）：
 
-1. **C 实现放主仓 `csrc/` 还是 SDK `third_party/homeagent-sdk/`？**
+1. **C 实现放主仓 `csrc/` 还是 SDK `third_party/hologramagentsdk/`？**
    - 当前已在主仓 `csrc/`（`ha_codec.{c,h}` 是权威源，Go 侧符号链接过去）
    - 若 SDK / 鸿蒙 / C SDK 侧也要复用，需定同步机制；搬进 SDK 则要走 SDK 冻结流程
 2. **`ha_json.c` 复用还是新写？**（复用会动 SDK 目录结构）