feat(controller): expose spec.env through REST API

[shenjiecode]

Summary

Follow up on the REST/CLI work intentionally deferred by #690.

WorkerSpec.Env and ManagerSpec.Env already exist in the CRD and are merged into container environments, but the public REST create/update DTOs do not carry them. As a result, agt apply -f accepts manifests containing spec.env and forwards the field to the REST API, where it is currently ignored.

This PR:

• carries env through Worker and Manager REST create/update requests;
• preserves omitted env on partial updates, replaces the complete user map when supplied, and supports explicit clearing with env: {};
• keeps env values out of Worker/Manager REST responses;
• adds handler coverage for create, replace, empty-string values, and clear semantics;
• adds an agt apply -f YAML projection regression;
• documents the field and secret-storage caveat in English and Chinese.

The existing system-wins collision policy and controller-to-backend propagation are unchanged.

Verification

• go test ./internal/... ./cmd/...
• make test-integration

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[shenjiecode]

Hi @shiyiyue1102 👋

Quick context: this follows up on the REST/CLI surface that #690 intentionally deferred — it carries spec.env through the Worker/Manager REST create/update DTOs, so agt apply -f no longer silently drops user env (raw kubectl apply already worked via #690). The existing merge semantics (system-wins, controller→backend propagation) are unchanged.

Since this is my first contribution to the repo, branch protection is holding a couple of things up. Could you help with:

1. Workflow approval — a couple of workflows show "awaiting approval" (the first-time-contributor gate), so CI hasn't actually run yet.
2. Review — happy to address any feedback.

The branch has no conflicts with main (cleanly mergeable), and I can re-sync it right before merge. Thanks for taking a look!

[shiyiyue1102]

Synced this branch with the latest main and resolved the changelog/current.md conflict. The resolution keeps the current post-release changelog and adds only the PR-specific spec.env entries.

Verification after the merge:

• go test ./internal/... ./cmd/... -count=1
• make test-integration (race-enabled)

Both passed locally. The PR is mergeable now; the remaining gate is the first-time-contributor workflows, which still need approval and a successful run.

---

已将最新 main 合入该分支，并解决了 changelog/current.md 冲突。解决结果保留 release rollover 后的当前 changelog，仅补回本 PR 的 spec.env 中英文条目。

合并后已验证：

• go test ./internal/... ./cmd/... -count=1
• make test-integration（启用 race 检测）

本地均已通过。PR 目前已可干净合并；剩余门禁是首次贡献者工作流，需要批准并成功运行。

[shenjiecode]

Hi @shiyiyue1102, thanks a lot for syncing the branch and running the local verification — really appreciated!

A heads-up: main moved again after your sync (#1103 landed later that day), so the branch had picked up another changelog/current.md conflict. I just re-synced to the latest main (now at 2ea0274) and resolved it — both What's New entries are kept. go build ./... and go test ./internal/... ./cmd/... pass on my side as well.

The branch is clean against main again. The only remaining gate is the first-time-contributor workflows: could you approve them so CI can run, and review when you get a chance? Happy to address any feedback. Thanks!

---

@shiyiyue1102 您好，非常感谢帮忙同步分支并跑本地验证！

提醒一下：您同步之后 main 又前进了（当天晚些时候 #1103 合入），分支又出现了一个 changelog/current.md 冲突。我已重新同步到最新 main（2ea0274）并解决——两条 What's New 条目都保留了。本地 go build ./... 和 go test ./internal/... ./cmd/... 同样通过。

分支现在与 main 干净对齐。剩余唯一门禁是首次贡献者工作流：能否请您批准一下让 CI 跑起来，方便时再 review？有任何反馈我都乐意处理。谢谢！