docs record hotfix process cleanup pitfall

docs/reference/dev-runtime-hotfix-runbook.md

@@ -59,6 +59,7 @@ NODE
 - 需要从 pod 内验证同一份实验时，优先复用同一个脚本在 D601、pod 和 CI 中运行；不要把探测逻辑在每个通道手写一遍。若必须临时写脚本，文件名包含目标和 commit，issue 中记录脚本路径、commit、命令和输出摘要。
 - pod 内部、D601 host、FRP 公网入口可能使用不同端口语义。`127.0.0.1:6667` 是 HWLAB 内部 cloud-api 常用端口，但 `6667` 属于 WHATWG bad port；Node/undici `fetch` 会在发包前直接报 `bad port`，包括临时 gateway 自己 poll `http://127.0.0.1:6667` 的场景。运行面实验脚本和 gateway 传输层必须用 Node `http/https` 原生 request，或改走公网 `http://74.48.78.17:16667` / service mesh 中不被 bad-port 拦截的入口。
 - 遇到 `fetch failed`、`bad port`、公网通而 pod loopback 不通时，先判断是不是实验工具栈限制，不要立即归因 cloud-api、FRP、k3s Service 或 gateway 离线。issue 复盘要记录具体 URL、调用库、错误字符串和替代入口。
+- 清理临时进程时不要用会匹配到清理脚本自身 `cmdline` 的宽泛字符串，例如 `hwlab-gateway-hotfix`；`node -e` 本身会把该字符串放进 `/proc/<pid>/cmdline`。清理脚本应匹配真实入口和参数组合，并显式排除 `process.pid`，或由启动脚本写 pidfile 后按 pidfile 清理。
 - 不要对已经很大的 hotfix ConfigMap 使用 `kubectl apply -f -`；`apply` 会尝试写入 `kubectl.kubernetes.io/last-applied-configuration`，可能超过 Kubernetes annotation 256 KiB 限制。局部更新用 `patch --type merge --patch-file`。
 - 多文件运行面覆盖第一次创建 ConfigMap 时也不要默认用 `kubectl apply -f -`；如果 data 可能超过 annotation 限制，先 `kubectl delete configmap <name> --ignore-not-found`，再 `kubectl create configmap <name> --from-file=...`，随后用 Deployment annotation 记录 hotfix 版本并 rollout。正式 CD 收口时必须删除这些 unmanaged ConfigMap/volumeMount，不让热修覆盖继续漂在运行面。
 - 不要通过会截断 stdout 的控制 CLI 把 `kubectl get configmap -o json` 回读到本地再 `replace`；大 data 可能被日志/截断污染成非法 JSON。只有在确认完整无截断的原生通道中，才允许对完整对象做 `kubectl replace -f -`。