feat: add process resource monitor

TEST.md

@@ -54,11 +54,11 @@
 
 ## T13 资源节点任务管理器曲线
 
-阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：运行 `bun scripts/cli.ts e2e run`，确认 `provider:system-status` 和 `frontend:system-monitor-visible` passed；再用浏览器登录 frontend，进入左侧 `资源节点` 和顶部 `资源监控` 子标签，确认可以像 Windows 任务管理器一样看到 CPU、Memory、Disk 当前用量和历史曲线，Memory 明确显示为不含 Linux page cache / buffer 的实际内存占用，并能执行 `Provider Gateway 升级` 的 `预检升级`。
+阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：运行 `bun scripts/cli.ts e2e run`，确认 `provider:system-status`、`provider:process-resource-status`、`frontend:system-monitor-visible` 和 `frontend:process-resource-sorting` passed；再用浏览器登录 frontend，进入左侧 `资源节点` 和顶部 `资源监控` 子标签，确认可以像 Windows 任务管理器一样看到 CPU、Memory、Disk 当前用量和历史曲线，Memory 明确显示为不含 Linux page cache / buffer 的实际内存占用；确认 `进程资源占用` 表默认按内存 RSS 降序，能点击 CPU、PID、用户、磁盘 I/O 等表头切换排序，且只通过 `查看原始JSON` 查看完整进程快照；最后确认能执行 `Provider Gateway 升级` 的 `预检升级`。
 
 ## T14 Provider Gateway 远程升级
 
-阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：如果本次变更修改了 `src/components/provider-gateway` 代码或行为，先确认 `src/components/provider-gateway/package.json` 的 `version` 已递增；运行 `bun scripts/cli.ts debug dispatch main-server provider.upgrade`，随后查看任务历史或 `bun scripts/cli.ts debug health`，确认 `provider.upgrade` 通过真实 WebSocket 下发并以 `mode: plan` 成功返回升级计划且计划中包含 `providerId`、`providerName`、`providerGatewayVersion`、`targetProviderGatewayVersion`、`policy: "always-enabled"`、`--no-deps`、`--force-recreate`、`oldGatewaySleepMs`、`promoteOnlyAfterCandidateValidation`、`candidateRestartPolicyAfterPromotion: "always"` 和 `candidateUsesOldContainerEnvironment`；对明确要升级或重建 `provider-gateway` 容器的计算节点，必须再运行 `bun scripts/cli.ts debug dispatch <PROVIDER_ID> provider.upgrade --mode schedule --wait-ms 15000`，确认任务成功、result 包含 updater 容器信息、候选 gateway 验证后节点重新上线，`providerGatewayVersion` 已上报目标新版本，且最终 provider-gateway 容器 Docker restart policy 是 `always`。在非主 server 的计算节点上，必须使用 `bun scripts/cli.ts --main-server-ip 74.48.78.17 debug dispatch <PROVIDER_ID> provider.upgrade --mode schedule --wait-ms 15000` 做同一验证，证明该节点能通过公网 frontend remote CLI 自测自动升级，且不需要指定 `--main-server-key`。正式执行计算节点 `provider-gateway` 重建/升级只能通过前端 `资源监控` 的 `执行升级` 或等价的 `provider.upgrade mode=schedule` 显式调度完成，不能通过 `bun scripts/cli.ts ssh <PROVIDER_ID>` 或 Host SSH 维护桥同步执行自重建命令，也不能通过 `PROVIDER_UPGRADE_ENABLED` 或等价开关禁用远程升级。
+阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：如果本次变更修改了 `src/components/provider-gateway` 代码或行为，先确认 `src/components/provider-gateway/package.json` 的 `version` 已递增；运行 `bun scripts/cli.ts debug dispatch main-server provider.upgrade`，随后查看任务历史或 `bun scripts/cli.ts debug health`，确认 `provider.upgrade` 通过真实 WebSocket 下发并以 `mode: plan` 成功返回升级计划且计划中包含 `providerId`、`providerName`、`providerGatewayVersion`、`targetProviderGatewayVersion`、`policy: "always-enabled"`、`--no-deps`、`--force-recreate`、`oldGatewaySleepMs`、`promoteOnlyAfterCandidateValidation`、`candidateRestartPolicyAfterPromotion: "always"`、`candidateUsesOldContainerEnvironment` 和 `candidateUsesHostPidNamespace`；对明确要升级或重建 `provider-gateway` 容器的计算节点，必须再运行 `bun scripts/cli.ts debug dispatch <PROVIDER_ID> provider.upgrade --mode schedule --wait-ms 15000`，确认任务成功、result 包含 updater 容器信息、候选 gateway 验证后节点重新上线，`providerGatewayVersion` 已上报目标新版本，且最终 provider-gateway 容器 Docker restart policy 是 `always` 并使用宿主 PID namespace。在非主 server 的计算节点上，必须使用 `bun scripts/cli.ts --main-server-ip 74.48.78.17 debug dispatch <PROVIDER_ID> provider.upgrade --mode schedule --wait-ms 15000` 做同一验证，证明该节点能通过公网 frontend remote CLI 自测自动升级，且不需要指定 `--main-server-key`。正式执行计算节点 `provider-gateway` 重建/升级只能通过前端 `资源监控` 的 `执行升级` 或等价的 `provider.upgrade mode=schedule` 显式调度完成，不能通过 `bun scripts/cli.ts ssh <PROVIDER_ID>` 或 Host SSH 维护桥同步执行自重建命令，也不能通过 `PROVIDER_UPGRADE_ENABLED` 或等价开关禁用远程升级。
 
 ## T15 待处理任务可追溯