feat: compress process gpid entires

[askyrie]

This PR is for:

• Server

[askyrie]

@claude review当前代码，用中文回复。

[claude]

Claude finished @askyrie's task in 5m 16s —— View job

---

任务进度

• 阅读仓库中的 CLAUDE.md 和相关说明（仓库内未找到 CLAUDE.md）
• 查看 origin/feature-gpid...HEAD 的变更并理解需求
• 审查代码正确性、边界条件和可维护性
• 用中文整理结论并更新评论

Review 结论

这次改动的主线很清晰：把 ProcessGPIDSyncResponse.gprocess_infos 从原始 protobuf bytes 改成 zstd 压缩后的 bytes，并通过 compress_algorithm 明确协议语义。agent 侧 agent/src/process_gpid.rs:378-401 也已经按该字段做了解压处理，主链路方向是对的。

不过我这里确认到 1 个需要修复的兼容性问题：

1. 仓库内现有诊断工具 agent_check 会被这次协议变更直接打坏。
   在 server/controller/trisolaris/services/grpc/agentsynchronize/process_info.go:121-124，服务端现在无条件返回 CompressAlgorithm = ZSTD，并把 GprocessInfos 改成压缩后的字节；但 cli/ctl/agent_check.go:377-385 仍然直接对 response.GetGprocessInfos() 做 Unmarshal()，完全没有根据 compress_algorithm 做解压。这样一来，只要 controller 返回了非空数据，这个诊断命令就会把压缩帧当成 protobuf 解析，最终走到 unmarshal process gpid info failed。这会让仓库内自带的排障/验收工具失效，也会让后续人工验证这个 PR 变得更困难。
   Fix this →

总结

除上面这个兼容性回归点外，我暂时没有在本次 diff 里看到更明显的正确性问题。建议至少把 agent_check 一并适配后再合入，否则协议改动会先把仓库内现有的调试入口打断。

[claude]

Claude finished @askyrie's task in 5m 23s —— View job

---

任务进度

• 阅读仓库中的 CLAUDE.md 和相关说明（仓库内未找到 CLAUDE.md）
• 复查 origin/feature-gpid...HEAD 的最新改动
• 核对 agent_check 补丁是否完整且无新回归
• 用中文更新 review 结论

Review 结论

我重新过了一遍这轮最新 diff，上次指出的 agent_check 兼容性问题已经补上了，目前我这边没有再看到新的阻塞性问题。

这次补丁的关键链路现在是对齐的：

• server/controller/trisolaris/services/grpc/agentsynchronize/process_info.go:121-124：controller 返回压缩后的 gprocess_infos，并显式带上 compress_algorithm = ZSTD。
• agent/src/process_gpid.rs:378-398：agent 端会根据 compress_algorithm 分支处理，NONE 走原始 bytes，ZSTD 先解压再 decode。
• cli/ctl/agent_check.go:385-399：agent_check 现在也会在 ZSTD 场景先解压，再做 Unmarshal()，已经和协议语义保持一致，不会再把压缩帧直接当 protobuf 解析。

我也顺手看了下这轮附带调整：

• server/controller/trisolaris/metadata/agentmetadata/process_gpid.go:63-87 把缓存内容改成压缩后的 bytes，并基于压缩结果做 MD5 去重；
• server/controller/trisolaris/metadata/agentmetadata/process_gpid.go:85 继续通过 version 变化驱动下游刷新；
• cli/go.mod 里把 github.com/klauspost/compress 升成直接依赖，和 agent_check 的新用法是匹配的。

总结

这轮我没有发现新的 correctness 回归。就当前 diff 看，之前 review 提到的兼容性缺口已经修复，可以继续往下走。