Could you say more about what overload is failing to resolve here? At first I thought it was something to do with the function f, but Codex deduces that it's actually these overloads of list.__add__? (lol @ the comment above those)

    # Overloading looks unnecessary, but is needed to work around complex mypy problems
    @overload
    def __add__(self, value: list[_T], /) -> list[_T]:
        """Return self+value."""
    @overload
    def __add__(self, value: list[_S], /) -> list[_S | _T]: ...

The core of MRE is not method definition, but implicit recursive attribute type inference (self.x = [self.x] + []).
The binary operation isn't the source of the bug; the same hang occurred when using list.__add__(). Also, the hang disappears if you put a literal or something in the list on the right-hand side. From this, we can see that the root of the bug is indeed a failure in overload resolution (of the generically defined list.__add__).

Is it guaranteed that we only need this new rule when the current cycle's type contains no Divergent? Or is it possible that it could contain Divergent in one spot, while also suffering from this overload resolution issue in another spot?

The responsibility of cycle_normalized is to guarantee the convergence of fixed-point iterations. If Divergent is properly included in the current iteration type, there is no problem in terms of convergence.

If the type of a previous iteration contained Divergent, but the current type does not, this may represent the progress of sound type inference, but it may also represent a divergence of fixed-point iteration due to the loss of Divergent (this is a case where the language feature itself lacks monotonicity and can lead to a reversal of type inference precision).
Simply unioning the two types in such cases was the behavior in the early stages of cycle_normalized. It was found that this ignored the case of "progress of sound type inference" and included "polluted types from previous iterations", leading to the solution in #23563.
However, the problem in astral-sh/ty#3614 is that the cases for unioning are now too narrow, missing "divergence due to the loss of Divergent". It is difficult to determine this simply from the type's shape, because types generally do not record the inference process they went through. However, using variants of DynamicType allows us to embed certain type inference failures. That's why I added DynamicType::AmbiguousOverload.

In principle, regression can occur in ways other than overload (although I couldn't think of any specific scenarios for that), but even in that case, the same treatment as this time would likely be applicable.