fix(promote): gate env pointer advance on in-scope deploy success

[joshua-temple]

Problem

Promotion finalize advanced the environment pointer (state.<env>.sha and state.<env>.version) to the new commit even when an in-scope deploy terminally failed or was cancelled. Because rollback_on_failure defaults to true, the auto-rollback job redeploys the environment's prior sha while finalize recorded the new one. In the default config, state then asserts a version the environment is not running: a state/reality inversion. The run is red, but the erroneous state advance is silent, and a re-dispatch with prod.sha == uat.sha is a silent no-op that never resurrects the failed deploy.

The rollback finalize already does the right thing (gateOnDeployResults aborts the write on failure/cancelled); promote was the outlier.

Fix

Finalize now gates the env-pointer advance on in-scope deploy success (inScopeDeployFailed), mirroring the rollback gate: the pointer is held at its prior value when any in-scope deploy terminally failed or was cancelled. Per-deploy success rows are still recorded individually, so a partial success is not lost and a re-dispatch re-plans and retries only the failed deploy. The in-scope set is the finalize's own deploy-result map, which is already scoped per component. Behavior is unchanged when every in-scope deploy succeeds, when a promotion advances an env with no deploys, and for --component finalize (siblings preserved).

Verification

• Added a unit test proving the pointer is held on an in-scope failure (RED before the fix, GREEN after), plus partial-success recording, rollback_on_failure: false, and happy-path advance.
• Corrected two existing tests that encoded the old behavior (env advancing over a failure/cancelled deploy).
• Extended the promote-rollback-runtime e2e scenario to assert the target pointer is held at the prior sha after a failed deploy, via an opt-in post-failure state sync in the harness (finalize runs under always(), so it commits state on a failed run; the harness previously could not observe that write).
• Root go build, go test, go test -race, and golangci-lint run all clean; e2e module builds and vets; all scenarios parse; verify --own-repo reports no drift.