release: CI check validating stack version bumps against migration evidence

A release-time check that answers, for a release candidate: does this bundle introduce schema changes that make the proposed version bump wrong?

A stack-pin diff is just version: 1.5.3 → 2.0.0 across a dozen charts. Nothing in it says whether a migration landed. In a monorepo that evidence is computable rather than something a human has to remember to declare — and a computed diff cannot be forgotten, whereas a declaration in a PR from two months ago can.

Shape: a shared Go library with per-stack configuration, so all three stacks under deploy/stacks/ share one implementation and can diverge in policy declaratively.

• tools/stack-upgrade-policy/ — resolves the stack's latest release tag, diffs it against HEAD over that stack's declared migration paths, classifies each changed file as additive or destructive (DROP, TRUNCATE, ALTER … DROP), flags deleted migration files, and compares the evidence against the proposed version bump.
• tools/ci/check-stack-upgrade-policy — bash entrypoint mirroring tools/ci/chart-service-edge (resolves repo root, builds the binary, propagates the real exit code). Takes --stack <id>.
• deploy/stacks/<stack>/upgrade-policy.yaml — per-stack config declaring which paths count as migration evidence. self-managed gets migrations/cassandra and migrations/openbao; the other two start empty, making the check a no-op until they need it.

Decision table: no migration changes → pass. Additive only → pass, report them. Destructive changes or deleted migration files with a non-major proposed bump → fail with the file list. Destructive with a major bump → pass, report. The evidence report prints on every run, not only on failure.

The proposed bump comes from the existing tools/ci/release-bump-type for-branch logic rather than a new mechanism.