refactor(security): Store 复用 Codec 加密能力 + 删 globalCodec 单例

## 用户裁定

> store也应该调用security的加密能力！

## 改动前的事实（实测）

两套**完全重复**的 AES-256-GCM：

    Store.seal/open     store.go:372,388    裸 base64
    Codec.Seal/Open     codec.go:113,139    enc:v1: 前缀 + 域隔离 + 幂等

算法、nonce 布局（前置 + io.ReadFull(rand)）、密钥环轮换逻辑全都一样，
只有 Codec 多了前缀与域隔离。

危害不是"代码重复"这么轻：

  · 两套实现各自演化，任何一侧的改动不会被另一侧的判据发现
  · Store 缺域隔离 ⇒ 变量库与配置共用密钥（安全倒退）
  · Store 缺前缀 ⇒ 无法区分"旧密文"与"明文"（惰性迁移的障碍）

## 本次做的

### Store 委托 Codec

    codecOf()            按当前 keys 环惰性构建（轮换后自动跟上）
    sealWithRing()       新格式（enc:v1: 前缀）
    openWithStoreRing()  兼容新旧两种格式，返回 needsMigrate

删除 Store 自带的 seal/open/openWithRing —— 现在**只有一处** AES-GCM。

### 域隔离（安全判据）

    storeCodecDomain  = "security/variables"
    configCodecDomain = "config-at-rest"

两者必须不同：同域时一处明文泄漏可推导另一处密文。

### 存量密文惰性迁移

旧格式是裸 base64 无前缀，而 Codec.Open 对无前缀输入**原样返回明文**
（那是给 config 的存量明文兼容）。直接交给 Open 会把密文当明文返回，
症状是"凭据回填出一个 base64 串"。

所以 Store 走 openWithStoreRing：

    enc:v1:... → Codec.Open
    裸 base64  → Codec.OpenLegacy（解开后立刻回写新格式）

不做启动时全量迁移（21G 数据目录的教训：迁移窗口越长越危险），
也不让两种格式永久共存（判据永不能要求"落盘都是新格式"）。

### 删 globalCodec 单例 → 归 Runtime

    security 模块 → rt.SetCodec(c) → ks.Security
    config 模块   → cfgReg.SetCodec(ks.Security.Codec())

ConfigRegistry 加 codec 字段（注入而非读全局），6 处 ConfigCodec() 改为
r.codecOf()；PluginSettings 经 p.registry 转调。
sdk.SecretsAPI 也加 codec 参数（插件加密能力来自它的内核实例）。

### 顺带

  · InitConfigCodec* / ClearConfigCodec 删除，改 NewConfigCodec 返回实例
  · homed-key-rotate 改为 构造 + reg.SetCodec（不再装全局）
  · bootstrap_order_test 的锚点从 InitConfigCodecWithOldKeys 改为
    NewConfigCodec（守的不变量不变，只是生效点写法变了）

## 判据（均经变异验证）

  TestNoPackageLevelSingletons          禁表补入 globalCodec
  TestStoreWritesPrefixedCiphertext     新密文必须带 enc:v1:（旧实现裸 base64 ⇒ 红）
  TestStoreAndConfigUseDifferentDomains 域隔离；改成同域 ⇒ 红（实测确认）
  TestLegacyCiphertextStillReadableAndMigrates  旧格式可读 + 落盘已升级
  TestRotationKeepsOldCiphertextReadable        轮换后旧条目仍可回填

## 验证

  go build ./...              PASS
  go vet ./...                PASS
  gofmt -l                    干净
  go test ./... -count=1      63 包全过，0 FAIL
  干净检出（git worktree）     build + security/config 测试全绿

## 数据风险

加密实现切换有丢数据风险，因此：
  · 先写往返判据，再改实现
  · 惰性迁移（读到才升级），不做启动全量重写
  · 旧格式与旧密钥环**都保留**读取路径

internal/kernelmod/security/mod.go

@@ -191,9 +191,14 @@ func Prepare(dataDir string, cfgReg *config.ConfigRegistry) (*sec.Runtime, error
 	}
 
 	// 配置落盘用的子密钥（域隔离：与别名密钥不共用）。
-	if _, err := sec.InitConfigCodecWithOldKeys(key, oldKeys); err != nil {
+	//
+	// ★ 2026-11-04（T3.2）：不再装全局单例，构造后**注入 cfgReg**。
+	// 注入必须早于下面的 EncryptExistingSecrets —— 它要靠 codec 加密存量明文。
+	cfgCodec, err := sec.NewConfigCodec(key, oldKeys)
+	if err != nil {
 		return nil, fmt.Errorf("config-encryption subkey derivation failed: %w", err)
 	}
+	cfgReg.SetCodec(cfgCodec)
 	// 把库里仍是明文的敏感项就地加密（幂等；升级路径必须跑）。
 	if n, merr := cfgReg.EncryptExistingSecrets(); merr != nil {
 		log.Printf("[security] existing sensitive config encryption incomplete (some entries still plaintext): %v", merr)
@@ -208,6 +213,7 @@ func Prepare(dataDir string, cfgReg *config.ConfigRegistry) (*sec.Runtime, error
 	}
 
 	rt := sec.NewRuntime(store)
+	rt.SetCodec(cfgCodec)
 	setPreparedRuntime(rt)
 
 	// ★ 全局策略基线（部署方兵底，用户 2026-10-29 裁定选项 B）。