fix: plan secret graph transitions

[vishr]

Summary

• read the active secret generation against the deployed release snapshot
• allow a normal deploy to add or remove secret-consuming workloads
• preserve partial/mixed-generation rejection for the graph that actually produced the live runtime

Failure reproduced

A deployed release had one secret-consuming workload. The next project added a second workload with an isolated SOPS file. Planning inspected the old runtime using the new two-workload graph and rejected the intentionally unlabeled newcomer as runtime workloads only partially select a secret generation.

Approach

The immutable ob.snapshot.yml is already the authority for rollback and secret push. Deployment planning now loads that snapshot to identify the old affected workload set, reads the old generation against that set, and stages the incoming graph under a fresh generation when inputs differ.

Validation

• regression test covers one deployed secret workload plus one newly secret workload
• 1,178 focused tests pass across app/engine/onebox
• full race suite: 1,609 tests across 19 packages
• just check passes, including tidy, vet, all Go tests, binary/doc generation, Astro check/build, and table checks
• staged gitleaks and git diff --check pass