fix: sub task race condition

[askyrie]

This PR is for:

• Server

[askyrie]

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

[claude]

Claude finished @askyrie's task in 6m 24s —— View job

---

任务进度

• 读取仓库说明与 PR 变更范围
• 分析改动文件并确认潜在问题
• 用中文整理并发布评审结论

评审结论

我主要看了这次并发保护和 vtap 清理逻辑的改动。整体上，cloud / kubernetes_gather_task 这部分为 map 和 resource 增加读写保护的方向是对的，不过目前我确认有一个会影响正确性的回归：

1. Unscoped() + 按 IP 建索引会把已软删除的 Host 当成当前资源，导致有效 vtap 被误删
   位置：server/controller/monitor/vtap/vtap.go:111-119, server/controller/monitor/vtap/vtap.go:198-201
   这里先用 Unscoped() 把 host_device 的软删除数据也读出来，再用 LaunchServerToHost[host.IP] = host 建索引。Host 本身带 SoftDeleteBase，也就是同一个 IP 可能同时存在“当前有效主机”和“历史已删除主机”两条记录（见 server/controller/db/metadb/model/platform_rsc_model.go:192-214）。现在 map 只保留最后一条，结果取决于查询返回顺序；一旦被已删除记录覆盖，下面 host.DeletedAt.Valid 就会成立，进而走到 deleteVTapOnResourceDeleted()，把实际上仍然关联着有效 Host 的 vtap 删掉。
   这类场景在宿主机重建 / 复用 IP 后是可以出现的，而且会造成误删，不只是日志噪声。建议把“当前活跃资源”和“已删除资源”分开索引，或者在冲突时始终优先保留 DeletedAt.Valid == false 的记录，再只在确实找不到活跃资源时才参考删除时间。

   Fix this →

说明

• 这次我没有在仓库里找到额外的 CLAUDE.md 仓库级说明文件。
• 本次是静态代码评审，未运行测试或做联调验证。
• 除了上面这个问题外，其余改动（GetKubernetesGatherTaskMap() 的快照、KubernetesGatherTask 上的 resource 锁、读取 subdomain/task map 时加锁）看起来方向正确。