docs: 命令登记与 SK_KEY_ENCRYPTION_SECRET 命名对齐

AGENTS 命令表、会话留档约定；骨架搭建指南与设计文档键名对齐代码。

docs/design/api_keys表字段设计.md

@@ -55,14 +55,14 @@
 
 - `key_hash`（HMAC-SHA256，不可逆）：只服务「命中判定」——没有它，每次查询都要把全部 key 送去上游验证
 - `key_ciphertext`（AES-256-GCM，可解密）：唯一用途是调上游
-- 密钥 `KEYS_MASTER_KEY` 经 env 注入（HKDF 派生 hmac / aes 子密钥）；**密钥丢失 = 全部 key 需重新登记**（记入部署文档）
+- 密钥 `SK_KEY_ENCRYPTION_SECRET` 经 env 注入（HKDF 派生 hmac / aes 子密钥）；**密钥丢失 = 全部 key 需重新登记**（记入部署文档）
 
 > **注解：为什么是两个字段（给非密码学背景的读者）**
 >
 > 两列各管一件事——`key_hash` 管「找得到」，`key_ciphertext` 管「用得起来」：
 >
 > - `key_hash` 像**单向粉碎机**：同样的输入永远产出同样的指纹，指纹却反推不出原文。输入 key 时（登记或查询），服务端算出的指纹与库中比对，命中即「已登记」，零上游调用；即便整库泄露，外人拿到的也只是指纹。选用 HMAC（而非裸哈希）是多掺一味只有服务器持有的「调料」：没有它，就无法用「猜测输入 → 对照指纹」的方式离线验证。
-> - `key_ciphertext` 像**保险箱**：用 `KEYS_MASTER_KEY` 加密锁存，轮询调上游时开锁取明文；AES-GCM 自带防篡改，密文被动过则解密直接报错。
+> - `key_ciphertext` 像**保险箱**：用 `SK_KEY_ENCRYPTION_SECRET` 加密锁存，轮询调上游时开锁取明文；AES-GCM 自带防篡改，密文被动过则解密直接报错。
 > - **两列并存的原因**：加密每次都掺随机数（同一 key 两次密文不同）→ 密文不能用于查找；哈希不可逆 → 指纹还原不出明文。「可查找」与「可还原」两个需求互斥，只能分存两份形态。
 > - **防线边界**：能同时接触数据库与环境变量的人（服务器运营方）防不住——这是已接受的信任模型前提；本设计防的是「数据库单独落到第三方手里」的常见拖库场景（SQL 注入、备份泄露）。
 > - 实现提示：两种算法均为标准件，Bun 内置 `crypto` 直接提供，无需第三方库。