1. Proposed title of this feature request

Console: re-prioritize the default update recommendations by freshness

2. What is the nature and description of the request?

Following up on console#13622, console ClusterVersion updates should pivot from the current:

Show recommended updates by default, regardless of age, with a Include versions with known issues toggle to include versions with known issues.

to something more like oc#1889's:

Prioritize displaying longest-hop targets in each 4.y by default, regardless of known issues, before discussing older versions.

For examples of the oc output, see this oc adm upgrade recommend fixture and this oc adm upgrade recommend --show-outdated-releases fixture.

The command-line is more constrained by the limited screen space and high cost of each interaction (typing a new command vs. clicking with a pointer, etc.), so I'm completely fine with console doing something else that doesn't have to hard-code "most-recent 2 in each 4.y are special". E.g. you could show the most recent one in each 4.y, with widgets to paginate/search if the user wants something older.

3. Why does the customer need this? (List the business requirements here)

The current interface prioritizes updates with no assessed risks. That's great, when they exist. But we sometimes have update regressions where we can't pin down the exposure perfectly in PromQL. For example, OCPCLOUD-2975's NonZonalAzureMachineSetScaling asks Azure cluster-admins to do MachineSet checks to see if they're exposed. Waiting until Red Hat ships a fix without engaging with the declared risk could delay Azure clusters that aren't exposed unnecessarily. And we'd like to be able to use conditional update risks to draw admin attention to issues that exist in the cluster but which are not tied to regressions, like critical alerts (RFE-5104). The current interface would hide these issues behind an Include versions with known issues toggle, and many admins may not click that toggle, and be unaware that Red Hat wants them to engage with the declared update risks and doesn't recommend "wait, and maybe some future OCP release will not be exposed" (e.g. no future OCP release becoming available is going to cause your critical alerts to stop fiing, but an admin looking into the firing alerts might get them resolved without needing any OCP updates).

The proposed change prioritizes newer patch releases, like 4.(y+1).tip and 4.y.tip, to increase ease of access QE-verified bugfixes.  And it deprioritizes 4.(y+1).old which, while it carries new features vs. the current cluster, also likely lacks bugfixes (or we wouldn't have shipped 4.(y+1).tip).

4. List any affected packages or components.

The oc adm upgrade recommend work is tracked separately, and has happened in OTA-1270 or is happening in OTA-1557. This RFE is about bringing one of those changes to the in-cluster web-console, and the console team and https://github.com/openshift/console component are the only ones expected to change when delivering it.