We sometimes tombstone or otherwise do not release a 4.y.z in a given week, when we do release 4.(y-1).z'. Hypothetical example:

1. Some bug shows up which makes 4.98.0-to-4.99 conditionally risky, and we've raised minor_min to 4.98.25 for new 4.99 builds.
2. Week 1: 4.98.90 and 4.99.50 are built. All is well.
3. Week 2: 4.98.91 and 4.99.51 are built, but 4.99.51 gets tombstoned.
4. Week 3: 4.98.91 enters fast channels, including fast-4.99.
5. Alice is on 4.98.0, and decides to move to 4.99 via fast-4.99. There are no recommended updates to 4.99.50 or 4.9.51 because of the long-standing minor_min floor.
6. Alice sees recommendations to 4.98.90 and 4.98.91, and heads off to 4.98.91 because it fixes more bugs.
7. Oh no, there are no recommendations to get from 4.98.91 to 4.99. Alice is stuck.
8. Week 4: 4.99.52 enters fast channels, with an update path from 4.98.91, and Alice can finally update.

What we want is to withhold 4.98.91 from fast-4.99 until it has an update path into 4.99, so when Alice tries to get to 4.99, we send her through 4.98.90, saving her the week+ of waiting for a new 4.99.z release that can update from 4.98.91.

Definition of done:

• The stabilization script learns about this new logic, so it will look up update recommendations and avoid promoting 4.(y-1) into 4.y channels until there will be update recommendations from the version being considered through to 4.y. At least for fast and later channels.