fix(planner): do not treat an already-current version as a rollback

[ViktorLindgren95]

What was changed

isRollbackScenario now returns early when the target version is already the current version.

Why?

Closes #609.

isRollbackScenario decided a rollback was underway purely from LastCurrentTime being set and recent. A version that is simply current has that timestamp set, so a deployment sitting on its current version was classified as a rollback on every reconcile. Within RollbackMaxVersionAge it logged:

Detected rollback scenario using LastCurrentTime. Warning: Auto-upgrade workflows ...
Monitor workflow executions for failures.

and once that age elapsed it logged Skipping rollback: the version's last current time exceeds the max rollback version age instead — both roughly every 10 seconds, for as long as the version stayed current. Nothing was actually rolled back: getVersionConfigDiff reaches the current == target branch and returns nil.

A version that is already current is not a rollback target, so the check returns false in that case.

Note on behaviour

This is not purely a logging change, and I would rather call it out than have it found in review.

Previously, when target and current matched, isRollbackScenario returned true and the strategy was replaced with AllAtOnce, which carries no gate — so the gate check in getVersionConfigDiff was skipped. With this change the configured strategy and its gate are retained in that state.

The case where that is observable: target equals current, a ramp is in flight (RampingBuildID != ""), and the gate's test workflows have not completed. Previously the ramp reset proceeded because the gate was skipped; now it waits on the gate. I believe returning false is the semantically correct answer, since a version that is already current cannot be rolled back to, but I am happy to take a different approach if you would prefer the strategy selection left untouched and only the logging changed.

Checklist

1. Closes [Bug] "Detected rollback scenario" logged on every reconcile for a steady-state current version #609

2. How was this tested:

Added TestGetVersionConfigDiff_NoRollbackWhenTargetIsAlreadyCurrent in internal/planner, covering a current version both inside and outside RollbackMaxVersionAge, asserting that no version config change is produced and that nothing is logged. Without the fix, both cases log.

go test ./internal/planner/ passes. Across ./internal/... the only failure is TestNewDeploymentWithOwnerRef_EnvConfigSDKCompatibility/without_TLS in internal/k8s, which fails identically on a clean checkout of main at fde47e73 and is unrelated to this change.

3. Any docs updates needed?

No. docs/configuration.md describes rollback detection in terms of a target version that was previously current, which this does not change.

[CLAassistant]

All committers have signed the CLA.

[ViktorLindgren95]

Moving this to draft while I complete an internal review on my side before signing the CLA. The change itself is ready and tests pass; this is purely a process step, and I'll mark it ready once that's resolved.

The analysis in #609 stands independently of this PR, so please feel free to pick the fix up there if it's useful in the meantime.

[ViktorLindgren95]

Internal review is done on my side, so marking this ready for review. Signing the CLA shortly.