chore(deps-dev): bump @types/node from 26.1.1 to 26.4.1

[dependabot]

Bumps @types/node from 26.1.1 to 26.4.1.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[clestons]

✅ APPROVE — #337

chore(deps-dev): bump @types/node 26.1.1 → 26.4.1 · head 957fdb106ed0。

纯类型包提升（@types/* 不进运行时），不跑 Codex PK。

• 新增包条目 0 个，1 条新 resolved 带 integrity，指向 registry.npmjs.org。
• 这是本批里唯一一个跨 minor（26.1 → 26.4）的，所以 Type Check 那道闸门是它的实质判据 —— pass。
  另外 Build 也 pass，两道合起来能覆盖「新类型定义把现有代码判红」这个唯一的现实风险。

---

共同上下文（这五个 dependabot PR 我一起量的，各自单独判）

① Security Audit 这道闸门是红的，而且合了这个 PR 之后还是红的 —— 原因与本 PR 无关。
我读了失败日志，红的是 npm audit 那一步，high=4 critical=0：

high  @nestjs/core               >=7.6.0-next.1
high  @nestjs/platform-express   *
high  @nestjs/swagger            >=5.0.9
high  multer                     <=2.2.0

这四个在 base lockfile 里都是生产依赖（dev=false：multer 2.2.0、@nestjs/* 12.0.1），
而这五个 PR 一行都没碰它们（我对每个 diff 都 grep 过 multer|@nestjs，命中数全是 0）。
所以「等 CI 全绿再合」在这个仓库现在做不到 —— 这是一笔独立的生产依赖欠账，值得单开一个 PR 收。
同一个 job 里还有第二处失败：Path does not exist: trivy-results.sarif（Trivy 那步没产出文件，上传步骤才报错），
这也是先于本 PR 就有的。

② 这五个 PR 的 lockfile 全部基于同一个 blob 4c6d8bb —— 谁先合，另外四个都得 rebase 重生成 lockfile。
Dependabot 会自己 rebase，但rebase 之后的那份 lockfile 没有人审过：合完第一个之后，
后面每一个都值得再看一眼「解析结果有没有变」，而不是沿用今天的读数。

[clestons]

⏸️ 补一条：本仓在 CC-115 B6 零合并冻结中 —— 上面那条 APPROVE 有效，但现在不要合。

（来自 yetanotheraa-validator-a5 会话：自 2026-09-05 起按 DSR 指令 §3 冻结，解冻条件是 DSR 发布 B6 evidence frozen。原因是论文证据链要钉在一个不动的部署上，合任何东西——包括纯 devDependency——都会让已冻结的证据失效。）

唯一的例外判据是「可外部触发 且 不可逆/涉资金密钥」。我上一条 review 里点名的那 4 条 high advisory 够不上这个例外，对方实测过：单一根因是生产依赖 multer 2.2.0，三个 @nestjs/* 只是经 platform-express 的传递效应；四条 advisory 全是 DoS 或上传限额绕过（不可逆=否、涉资金密钥=否），而且本服务全部 32 条 HTTP 路由里 FileInterceptor/FilesInterceptor/AnyFilesInterceptor/@UploadedFile/multipart 命中数全为 0，multer 从未挂到任何路由上 —— 四条 advisory 都要求攻击者发一个 multer 真正会去解析的 multipart 请求，这个前提在本 build 不成立。

同时订正我上一条 review 里一个会让人白跑一趟的暗示：这笔账 npm audit fix 修不掉。multer@latest = 2.3.0（修复版存在），但 @nestjs/platform-express@latest 已经是 12.0.1 且仍把 multer 钉在 2.2.0。上游没跟进，只能在 package.json 加 overrides 强推 2.3.0，再验 platform-express 在 2.3.0 上没有行为回归 —— 这是一个需要判断的改动，不是 dependabot 能代劳的。

另外一条补充（也来自对方实测）：本机默认 registry 是 npmmirror，而它没有实现 audit 接口 —— npm audit 直接返回 [NOT_IMPLEMENTED] /-/npm/v1/security/*。所以任何人在本地跑 npm audit 会看到一个长得像「没问题」的错误输出。这让我上一条里说的「收敛混源 lockfile」从整洁问题升级成了量具问题，建议和 audit 欠账并成同一个 follow-up。

解冻之后再推进合并。