fix(证书管家): writeapi.usj.cc 证书纳管（相对软链接）；pushall 改为先 rebase 再推

用户：「动手 推送吧」—— 动手处理两个有死线的遗留。

一、writeapi.usj.cc 的证书（12 月会断）→ 已解决

现状复核推翻了上一轮的判断：
  · 上一轮记的「它的 ssl_certificate 引用不在 /www/sites/ 树里」是**错的** ——
    /www/conf.d/writeapi.usj.cc.conf 里明确写着
    ssl_certificate /www/sites/writeapi.usj.cc/ssl/fullchain.pem;
  · 真正原因是**它在 1Panel 面板上根本不是一个网站**（面板共 11 个站点，没有它），
    所以 `findWebsite('writeapi.usj.cc')` 必然抛「找不到网站」→
    加进 one_panel_sites 只会让**每次续期都报错**（而且只警告不阻断，长期没人发现）
  · 实测确认：redeploy 时其余 5 个站点正常，只有它失败

解法：**不写一行代码** —— 它与 artalk.usj.cc 本来就同用一张 *.usj.cc 证书，
让它用**相对软链接跟随 artalk** 即可，随续期自动更新：
  ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem /1panel/1panel/www/sites/writeapi.usj.cc/ssl/fullchain.pem

★★ 踩到的坑：软链接**必须相对路径**
  宿主 /1panel/1panel/www/sites/ ↔ 容器内 /www/sites/（1Panel 的 openresty 跑在容器
  `1Panel-openresty-Kmh2`）。第一版写成宿主绝对路径 → **容器侧断链** →
  nginx -s reload **静默失败**（保留旧配置、服务不中断、握手照旧拿旧证书）→
  表面全绿，真实后果是「等某天 nginx 重启，writeapi 的 HTTPS 直接挂」。
  唯一线索是 worker 进程的启动时间没变 —— **所以验收必须看 worker 是否真的重启**。

验收（全部实测）：
  替换前 CN=usj.cc    / LiteSSL RSA CA / 2026-12-07（mtime 10-04 21:50）
  替换后 CN=*.usj.cc  / LiteSSL ECC CA / 2027-01-04
  容器内 head -1 → -----BEGIN CERTIFICATE----- / -----BEGIN PRIVATE KEY-----
  预检 syntax is ok / test is successful
  reload → signal process started；**worker 22:51:39 重启**（证明软链接真被读了）
  握手 SNI=writeapi.usj.cc → *.usj.cc / Jan 4 2027；实访 /health → HTTP 200

新增 deploy/cn-certkeeper/src/dump-cert.mjs：把 KV 里（AES-GCM 加密）的证书导成明文 PEM，
补上「KV ↔ 手工 vhost 磁盘文件」之间原先不存在的桥。只读，用完即删（含明文私钥）。

操作层的两个坑（写进文档）：
  · 1Panel 文件 API **拒绝写 .mjs**（返回 500「目标路径不存在」，实为可执行扩展名过滤）；
    往新建的 root:root 700 目录写也会失败 → 临时脚本用
    `docker exec -i … sh -c 'cat > 路径' < 本地文件` 送
  · cnrun.py（1Panel 计划任务通道）偶发「退出码 0 但零输出」；
    加 `timeout 30 docker exec …` 包一层即稳定，判断状态优先看容器内直接证据

二、配置回退 + 文档更正

  · certkeeper-config.mjs：把 writeapi 从 one_panel_sites 移除，换成一段注释说明
    「它不是 1Panel 站点，别加进来」+ 软链接做法 + 必须相对的警告；
    线上 config.kv 同步回退（sha256 与改动前完全一致 ccac2530…）
  · 更正「3 个手工 vhost」的说法：vaultwarden **是**正常纳管的站点（面板 #13，
    主域名 vw.usj.cc，别名才是 vaultwarden）→ 手工 vhost 实际只剩 writeapi + dnsapi
  · dnsapi.usj.cc 重新定性为**不做**：它是 cn-dns-helper 的反代入口
    （proxy_pass 127.0.0.1:8018，仅 HTTP），去留应与 cn-dns-helper 一起决定，
    不该单独给一个待退役的服务加 HTTPS

三、pushall 加固：先 fetch + rebase 再推（本次真实撞到的问题）

推 CNB 时被 rejected —— 因为线上写作后台（editor-api）发文章会**直接推 main**，
本机两笔提交与之分叉。这不是异常，是**日常**。原别名直接 push，必然反复撞。

  · 新增 scripts/pushall.sh：fetch → 已在远端之后则 rebase → 推所有远端
    - 冲突时**停在 rebase 中途**交人工（不强推、不丢东西）
    - 工作区不干净时 git 自己会拒绝 rebase（不会吞改动）
    - 任一远端失败**不改判另一个**（主仓失败辅仓照样推），退出码以第一次失败为准
    - ⚠️ 修了自己写的一处疏漏：`if ! cmd; then ec=$?` 的 $? 是**取反后**的结果（0），
      不是 git 的退出码 —— 必须显式 ec=1（靠 set -o pipefail 保证管道退出码不被 sed 掩盖）
  · setup-cnb-remotes.sh 的别名改指向脚本；README 脚本表补这一行

四、文档

  · docs/证书管家.md：速览表「已知遗留」→ 已解决；§9.14 遗留段重写（含纠正自己写错的判据
    「路径像不像不构成判据，要直接查面板站点清单」）；**新增 §9.15**
    「手工 vhost 的证书：用相对软链接跟随已纳管站点」（机制 + 路径坑 + 三条验收 + dump-cert 用法）
  · docs/架构精简候选.md：候选 5 标记完成，补上「为什么 A 走不通、B 未采用」；
    执行顺序里划掉它
  · 架构总览.md：§5.7「已知遗留」重写（2 个手工 vhost + vaultwarden 更正）；
    §6 待办 #13 改为已解决、#14 标注完成

docs/证书管家.md

@@ -19,7 +19,7 @@
 | CA | LiteSSL / freessl.cn（EAB 继承 certimate 账户，见 §9.10） |
 | 自测 | 125/125 通过；`npm run typecheck` 零错误 |
 | 数据目录 | 容器内 `/data`，7 条凭据（AES-GCM）+ 1 条 config |
-| **已知遗留** | `writeapi.usj.cc` 等 3 个手工 vhost 不在站点管理面内（§9.14 末节）—— 证书是文件拷贝，需单独纳管 |
+| **手工 vhost 的证书** | ✅ **已解决**（2026-10-06）：`writeapi.usj.cc` 靠**相对软链接跟随 `artalk.usj.cc`**，随续期自动更新 —— 机制与坑见 §9.15 |
 
 ---
 
@@ -594,8 +594,13 @@ private importSigningKey(): Promise<CryptoKey> {
 > 判据用**证书记录自带的 `websites` 字段**（1Panel 自己算的引用关系），
 > 比遍历 `/websites/{id}/https` 更权威。删除接口 `POST /websites/ssl/del {"ids":[...]}`。
 >
-> ⚠️ 3 个手工建的 nginx vhost（`dnsapi.usj.cc` / `writeapi.usj.cc` / `vaultwarden`）
-> **不归 1Panel 站点管理**，证书是**文件拷贝**（指纹与 id 11 一致），与证书库记录解耦。
+> ⚠️ **2 个**手工建的 nginx vhost（`dnsapi.usj.cc` / `writeapi.usj.cc`）
+> **不归 1Panel 站点管理**，证书是**文件拷贝**，与证书库记录解耦。
+>
+> 🔧 **2026-10-06 更正**：这里原先写的是「3 个」，把 `vaultwarden` 也算进去了 ——
+> **实测错**：`vaultwarden` 是**正常纳管**的 1Panel 站点（面板 #13，主域名 `vw.usj.cc`，
+> 别名才是 `vaultwarden`），续期时会被正常绑定。
+> 手工 vhost 只剩 `writeapi.usj.cc`（已用软链接解决，§9.15）与 `dnsapi.usj.cc`（待随 `cn-dns-helper` 一起决策）。
 
 ### 9.7 ★ 未决冲突：t-t.live 的「两套管理」 → 已定案：本项目接管
 
@@ -695,7 +700,7 @@ ssh.200181.xyz 公网 → 解析失败 / 源站 → 48 天 ← 修复了「天
 | Worker 的续期 cron `10 4 * * *` | **停掉**。`wrangler.toml` 的 crons 改为 `["17 3 * * *", "0 * * * *"]`；`index.ts` 里整个 renew 分支删除 |
 | Worker 的签发入口 `POST /ssl/issue` | **改成 501 硬拒绝**，响应里给出「去国内机执行」的 curl 命令；后台按钮文案改成「签发/续期（在国内机）」 |
 | `usj.cc` 的 SAN 升级为 `usj.cc;*.usj.cc` | **接受**（线上原本是单名 `CN=usj.cc`，升级后一张证书同时覆盖主域与全部子域） |
-| `dnsapi.usj.cc` 上 HTTPS | 仍未做；`cn-certkeeper` 只绑 `127.0.0.1:8019`，暂不走反代 |
+| `dnsapi.usj.cc` 上 HTTPS | **不做**（2026-10-06 重新定性）：它其实是 `cn-dns-helper` 的反代入口（`proxy_pass http://127.0.0.1:8018`），而 `cn-dns-helper` 大概率已是遗留（见 `架构精简候选.md` 候选 2）→ **去留应与它一起决定**，不该单独给一个待退役的服务加 HTTPS |
 | 停 certd / 接管 t-t.live | **certd 根本不存在**，真正的竞争者是 certimate 容器；处理方式见 §9.10 |
 
 ### 9.9 ★★ 上线前修掉的两个 ACME 客户端真实 bug（只有打真 CA 才会现形）
@@ -964,14 +969,108 @@ docker start 1Panel-certimate-OKCO
 > 回滚：`sqlite3 data.db "update workflow set enabled=1 where id='bsmqgpygir8l01s';"`
 > （库在 `/1panel/1panel/apps/certimate/certimate/data/data.db`，同目录留了 `.bak-20261006-200609`）
 
-#### 遗留：`writeapi.usj.cc` 的手工 vhost 不在本项目的部署面内
+#### 遗留（已解决）：`writeapi.usj.cc` 的手工 vhost 不在本项目的部署面内
+
+> ✅ **2026-10-06 当天解决** —— 解法与踩到的坑见下一节 §9.15。
+> 下面保留**当时的诊断**，但请注意其中一处**判断是错的**（已在 §9.15 更正）。
 
 全网核验时发现 `writeapi.usj.cc` 的 `ssl/fullchain.pem` 仍是 **旧证书**
 （`CN=usj.cc` / RSA / LiteSSL RSA CA / 到期 2026-12-07，mtime 2026-10-04 21:50）。
 
-原因：它是 **1Panel 手工建的 vhost**，nginx 的 `ssl_certificate` 引用**不在 `/www/sites/` 目录树里**
-（`grep -rn ssl_certificate sites/writeapi.usj.cc/` 无结果），因此**不走站点管理**，
-`/websites/{id}/https` 的绑定操作碰不到它 —— 证书是**文件拷贝**，与证书库记录解耦。
+原因：它是 **1Panel 手工建的 vhost**，因此**不走 1Panel 的站点管理面** ——
+`/websites/{id}/https` 的绑定操作碰不到它，证书与证书库记录解耦。
+
+⚠️ **当时写错的一点**：本文档原先记的是「它的 `ssl_certificate` 引用不在 `/www/sites/` 目录树里」
+（依据是一次 `grep -rn ssl_certificate sites/writeapi.usj.cc/` 没结果）。
+**实测推翻**：`/www/conf.d/writeapi.usj.cc.conf` 里明确写着
+`ssl_certificate /www/sites/writeapi.usj.cc/ssl/fullchain.pem;` —— 路径**在**管理树里。
+真正的原因是**它在 1Panel 面板上根本不是一个站点**（面板共 11 个网站，没有它），
+所以「按站点名去绑定」这条路径永远找不到目标。
+> 教训：**「路径像不像」不构成判据，要直接查面板的站点清单**（`POST /websites/search`）。
+
+---
+
+### 9.15 ★ 手工 vhost 的证书：用**相对软链接**跟随已纳管站点
+
+**背景**：`writeapi.usj.cc`（写作后台 `post.usj.cc` 的 API 入口）是手工 vhost，
+不在 1Panel 站点清单里。而它与 `artalk.usj.cc` 用的是**同一张证书**
+（`usj.cc` 的 SAN = `[usj.cc, *.usj.cc]`，两者都被覆盖）。
+
+**解法 —— 不写一行代码**：
+
+```bash
+# 宿主上执行（路径是宿主视角；容器内是 /www/sites/...）
+D=/1panel/1panel/www/sites/writeapi.usj.cc/ssl
+ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem "$D/fullchain.pem"
+ln -sfn ../../artalk.usj.cc/ssl/privkey.pem   "$D/privkey.pem"
+```
+
+这样 `artalk` 每次续期被 1Panel 物化新证书时，`writeapi` **通过软链接自动跟随**；
+1Panel 绑定 artalk 时本来就会 reload nginx，所以 writeapi 那边也一并生效 ——
+**零代码、零新增凭据、零额外机制**。
+
+#### ★★ 坑：软链接**必须用相对路径**（写绝对路径会在容器里断链）
+
+1Panel 的 openresty 跑在容器 `1Panel-openresty-Kmh2` 里，挂载关系是：
+
+| | 宿主 | 容器内 |
+|---|---|---|
+| sites 根 | `/1panel/1panel/www/sites/` | `/www/sites/` |
+
+所以宿主绝对路径 `/1panel/1panel/www/sites/artalk.usj.cc/ssl/privkey.pem`
+**在容器里不存在** → 软链接在容器侧**断链** → nginx 重启/reload 时读不到证书。
+
+**这个坑的隐蔽之处**：断链后 nginx 的 `-s reload` 会**静默失败**（保留旧配置、服务不中断），
+握手看起来一切正常（拿到的还是旧配置里那张内容相同的证书），
+**只有 worker 进程的启动时间没变**这一条线索 ——
+真实后果是「**等某天 nginx 重启，writeapi 的 HTTPS 直接挂**」。
+
+**所以验收必须包含这三条**（缺一不可）：
+
+```bash
+# 1) 容器内能真正读到（最关键 —— 宿主侧 ls 看不出断链）
+docker exec 1Panel-openresty-Kmh2 head -1 /www/sites/writeapi.usj.cc/ssl/privkey.pem
+#    应输出 -----BEGIN PRIVATE KEY-----
+
+# 2) 配置预检
+docker exec 1Panel-openresty-Kmh2 /usr/local/openresty/bin/openresty -t
+
+# 3) reload 后 **worker 进程确实换了**（只看握手会被"内容相同的旧证书"骗过）
+docker exec 1Panel-openresty-Kmh2 /usr/local/openresty/bin/openresty -s reload
+ps -eo pid,lstart,args | grep "nginx: worker" | grep -v grep
+```
+
+#### 把锁在 KV 里的证书取出来：`src/dump-cert.mjs`
+
+证书在数据目录的 KV 里（AES-GCM 加密），手工 vhost 用的是磁盘 `.pem`，两者原先没有桥。
+新增的 `deploy/cn-certkeeper/src/dump-cert.mjs` 负责这一步（只读，不签发不部署）：
+
+```bash
+# 脚本要先送进容器（1Panel 的文件 API 会拒绝 .mjs，见下）
+docker exec -i cn-certkeeper sh -c 'cat > /tmp/dump-cert.mjs' < deploy/cn-certkeeper/src/dump-cert.mjs
+docker exec cn-certkeeper node /tmp/dump-cert.mjs usj.cc
+# 产物落在 /data/tmp/（宿主 <数据目录>/tmp/）—— ★ 含明文私钥，用完立刻删
+```
+
+**两个操作层面的坑**：
+
+- **1Panel 的文件 API 拒绝写 `.mjs`**（`/files/save` 返回 500「目标路径不存在」）。
+  这是它的可执行扩展名过滤（防脚本落盘）。同样地，往**新建的 root:root 700 目录**写也会失败。
+  临时脚本的可靠送法是 `docker exec -i … sh -c 'cat > 路径' < 本地文件`。
+- **「命令带 `docker exec` 时远程执行返回空」**：本地 `.editor-tmp/cnrun.py`（1Panel 计划任务通道）
+  偶发出现「退出码 0 但零输出」。加 `timeout 30 docker exec …` 包一层即可稳定复现结果；
+  判断真实状态时**优先看容器内的直接证据**，不要只看那一次调用的输出。
+
+#### 验收记录（2026-10-06）
+
+```
+替换前：CN=usj.cc      / LiteSSL RSA CA / 到期 2026-12-07（mtime 10-04 21:50）
+替换后：CN=*.usj.cc    / LiteSSL ECC CA / 到期 2027-01-04
+软链接：fullchain.pem -> ../../artalk.usj.cc/ssl/fullchain.pem
+容器内可读：head -1 → -----BEGIN CERTIFICATE----- / -----BEGIN PRIVATE KEY-----
+预检：syntax is ok / test is successful
+reload：signal process started；worker 于 22:51:39 重启（**证明软链接真的被读了**）
+握手：SNI=writeapi.usj.cc → CN=*.usj.cc，notAfter=Jan 4 2027
+实访：https://writeapi.usj.cc/health → HTTP 200
+```
 
-功能上没问题（该证书 SAN 含 `*.usj.cc`，能覆盖 `writeapi.usj.cc`），但：
-算法仍是 RSA、62 天后到期、且不会随本项目的续期自动更新 → **需要单独纳管**。