Bounded type var with covariant Iterator assignment

[grievejia]

Describe the Bug

Minimal repro:

from typing import Iterator

class NumberStream[_R: int]:
    def __init__(self, start: _R) -> None:
        self._val = start

    def __iter__(self) -> Iterator[_R]:
        return iter([self._val])

    def __next__(self) -> _R:
        return self._val

# NumberStream(start=0) -> NumberStream[int]. int satisfies bound.
# Iterator[int] is subtype of Iterator[int | None] (covariance).
# Pyrefly rejects: "int | None not assignable to upper bound int"
stream: Iterator[int | None] = NumberStream(start=0)  # FP: bad-specialization

No other type checker emits the error.

Sandbox Link

https://pyrefly.org/sandbox/?project=N4IgZglgNgpgziAXKOBDAdgEwEYHsAeAdAA4CeS4ATrgLYAEALqcROgOZ0Q3G6UN0BJBjEqoGvADropAYyio4cOgDkArjWwiAyg0oxUNANoB9AEqJO6BgF1EUug7qYYYOseOsIDdwAo4MKDAAGjo4BlQ%2BCzMASjoAWgA%2BFVx0GDt0R0zQgLBCYwA3VCg6AF5Q8L4pe0dnV3cvEV9-QNjEwWFRcUoTU1tqrLo9BlVKDIbKH0Nm3IKi62iqjJqXN2NU-G9jPxzWpLN0gYchkYzpvMKoRYBiFXVNSh09Az8KhhKABl3bjW1dfSNWDZCJZ%2BGgGBA4JB4HQ8KosIQpDchCIxLxDIDrJwlHBVNgmMQYHRcK5kZ00YC6AAfZKpTE%2BGS4QqUCAYGQwaII9A3AAKpD0YCgpEGMAAVjAZAw4BYJCAKdTlClCehcPwFHAIGx0KhsLBGLg6KpiATKDDcHDMCCZVIwk8aBZSajunKaTBMWU1D8Hn9nmEIm9Pg4bgAxbkWbCoTBxOAEmQsqAQABeYggKRAQRAqnBUDgJHIiBANwAqlmvEKwHCJSn0HBFrU6GBeDQxGs7iIfPgLICvjaDo5jqN6zKPfcLMB8ABfK3oNMgMj8wWEcQ0KAUHl8lyC0IYHAEOgM9CQNgjZMpTk3LQwQkACwYDGIUoA9A%2B5xvSIReGwHzB0A-MLgZHAD77oex7gikD71rwdCoIU0DarqwEaqBVZEsQYHVpyZAMFeKRxPkIjqikpR0DKADMhAAIwAExTiA47pqglb4UG0AwBQaBYHgRBkHRQA

(Only applicable for extension issues) IDE Information

No response

[grievejia]

I'm getting the impression that the fundamental issue here is that the solver doesn't properly handle bounded type vars under covariant structural matching: when the structural protocol check produces R <: int | None (via covariance), the solver doesn't properly intersect this upper bound with _R's existing bound _R <: int. If it did, it would derive R <: int and everything would work with the original hint-first ordering.

I can't help but wondering if this is actually a symptom of #105 (cc. @rchen152). Without deferred solving, it feels like any kind of tweak around the ordering between contextual hint application and argument based inference is just workarounds that trades one kind of bad behavior with another kind.

[rchen152]

This is fixed.