fix: treat LRR-failed-but-LCR-different as transient in traffic config - #16702

Fixes: #16698

When a Knative revision fails, the following state can occur in the Configuration:

• LatestReadyRevisionName = "rev-v2" (the now-failed revision)
• LatestCreatedRevisionName = "rev-v3" (a new revision being deployed)
• Ready = Unknown (since LRR != LCR)

In this state, the Route controller's addConfigurationTarget would:

1. Find LRR = "rev-v2" (non-empty, so NOT taking the errUnreadyConfiguration path)
2. Fetch rev-v2 from lister → find it is NOT ready (failed)
3. Call errUnreadyRevision(rev-v2) → isFailure = true (since rev.Ready = False)
4. Call MarkRevisionFailed on Route → Route.AllTrafficAssigned = False (permanent)

This caused the Route to become permanently stuck even when a new revision
(rev-v3) is actively being deployed to replace the failed one. The Route would
not automatically recover — users had to manually delete the failed Revision
to force a re-reconciliation.

The fix: in addConfigurationTarget, before calling errUnreadyRevision when the
LRR revision is found to be failed, check if LCR != LRR. If they differ, a new
revision is in flight, so we should return errUnreadyConfiguration instead —
which produces isFailure=false and lets the Route retry gracefully.