feat(ssl): ACME 自动签发与自动续期，实现证书全生命周期闭环

证书管家此前只做「探针」（查剩余天数），现补齐签发+部署两个环节，
参照 certimate（MIT）的 DNS-01 流程自行实现，不再依赖闭源 certd。

新增（纯 WebCrypto，零 npm 依赖）：
- lib/acme.ts        ACME v2 客户端：ES256 JWS（原始 r||s）、RFC7638
                     thumbprint、EAB、badNonce 重试、DNS-01、手写 DER CSR
- lib/dnsprovider.ts DNS-01 适配：DNSPod（TC3-HMAC-SHA256）、Cloudflare
- lib/deployer.ts    部署适配：多吉云 CDN、1Panel 站点（幂等换证书）
- lib/certissue.ts   编排：探针判剩余天数 → 注册/复用账户 → 签发 → 落库
                     → 逐目标部署；RENEW_BEFORE_DAYS=30
- routes/ssl.ts      新增 POST /ssl/issue、GET /ssl/renew-check、
                     POST /ssl/selfcheck（环境自检，只读不签发）
- index.ts + cron    每日 04:10 自动续期检查；cpu_ms 提到 60s

与 certimate 的差异：certimate 每个 workflow 每天无条件重跑，
这里改为先探针查剩余天数、低于阈值才签，省 CA 限速额度。

实测修正（易误判，勿回退）：
- 多吉云 bind 参数是 {id, domain}，非 {cert_id}（用假 id 对照实验确认：
  cert_id 回「域名不存在」= 参数被无视）
- 多吉云上传私钥字段是 private；列域名用 /cdn/domain/list.json
- 1Panel 必须用 /api/v2/（v1 返回 HTTP 200 但正文是 HTML 停用页）
- 1Panel HTTPS 配置字段是 SSL（大写），写错会导致每次续期都重绑
- LiteSSL ACME 目录须带 /v2：acme.trustasia.com/acme/v2/directory

测试：selftest-acme 16/16（CSR 过 openssl 验签、JWS 过 Node crypto 验签）、
selftest-deploy 18/18、selftest:ssl 117/117、UI 全过、tsc 干净

blog-admin/tools/seed-ssl-config.mjs

@@ -85,6 +85,17 @@ const CONFIG = {
       san: ['usj.cc', '*.usj.cc'],
       dns: 'tencent-usj',
       deploy: ['dogecloud', '1panel'],
+      // ★ 站点名必须与 1Panel 里的 `primaryDomain` 或 `alias` 精确对上，
+      //   否则部署时会被跳过。下面这些是 2026-10-06 从面板实测出来的
+      //   （面板上**没有** primaryDomain 为 `usj.cc` 的网站 —— 它只是证书名）。
+      dogecloud_domains: ['usj.cc', 'www.usj.cc', 'artalk.usj.cc'],
+      one_panel_sites: [
+        'artalk.usj.cc', // blog 评论后端
+        'openlist.usj.cc', // 网盘
+        'wifi.usj.cc',
+        'openwrt.usj.cc',
+        'vw.usj.cc', // vaultwarden（alias 才是这个名字）
+      ],
       disabled: false,
     },
     {
@@ -92,6 +103,7 @@ const CONFIG = {
       san: ['t-t.live', '*.t-t.live'],
       dns: 'tencent-tt',
       deploy: ['1panel'],
+      one_panel_sites: ['t-t.live', 'www.t-t.live', 'pl.t-t.live', 'pwd.t-t.live', 'certd.t-t.live'],
       disabled: false,
     },
     {
@@ -99,6 +111,7 @@ const CONFIG = {
       san: ['200181.xyz', '*.200181.xyz'],
       dns: 'cloudflare',
       deploy: ['1panel'],
+      one_panel_sites: ['ssh.200181.xyz'],
       disabled: false,
     },
   ],
@@ -152,6 +165,10 @@ console.log('域名配置（明文）:');
 for (const d of CONFIG.domains) {
   const dnsOk = ACCESS.some((a) => a.name === d.dns);
   console.log(`  ${dnsOk ? '✓' : '✗'} ${d.name.padEnd(14)} dns=${d.dns.padEnd(12)} deploy=[${d.deploy.join(', ')}]  SAN=${d.san.join(';')}`);
+  // ★ 把「要绑到哪些站点」也打出来 —— 这是最容易配错、且错了之后
+  //   只会在部署时才暴露的一环（站点名对不上 = 静默跳过，站上还是旧证书）。
+  if (d.dogecloud_domains?.length) console.log(`      多吉云域名: ${d.dogecloud_domains.join(', ')}`);
+  if (d.one_panel_sites?.length) console.log(`      1Panel 站点: ${d.one_panel_sites.join(', ')}`);
   if (!dnsOk) throw new Error(`域名「${d.name}」引用的 DNS 凭据「${d.dns}」不在凭据清单里`);
 }