Type confusion with protocol attributes when explicitly subclassing protocol

Bug Report

When type hinting an attribute on a protocol, and then explicitly subclassing the protocol in a class and performing assignment on the attribute, mypy appears to lose the type information on the attribute. In one case, mypy determines the type is whatever can be inferred from the assignment, and in another case, mypy cannot determine the type.

I've looked at Python's documentation for explicitly subclassing a Protocol (docs) as well as the documentation in mypy for Protocols (docs) and I believe this should work.

To Reproduce

Case 1: Incompatible types in assignment

from typing import Protocol


class InventoryItemProtocol(Protocol):
    val: int | None


class InventoryItemMixin(InventoryItemProtocol):
    def set(self) -> None:
        self.val = 1


class InventoryItem(InventoryItemMixin):
    def __init__(self) -> None:
        self.val: int | None = None

Case 2: Cannot determine type

from typing import Protocol


class ValProtocol(Protocol):
    val: int | None


class Runner(ValProtocol):
    def run(self) -> None:
        if not self.val:
            raise ValueError

        self.val = 1

Expected Behavior

Both programs pass type checks.

Actual Behavior

Case 1

sandbox_protocol1.py:15: error: Incompatible types in assignment (expression has type "int | None", base class "InventoryItemMixin" defined the type as "int")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Case 2

sandbox_protocol2.py:10: error: Cannot determine type of "val"  [has-type]
Found 1 error in 1 file (checked 1 source file)

Your Environment

mypy --version
mypy 1.17.1 (compiled: yes)

python --version
Python 3.12.2

Start by running the two protocol examples from the issue with mypy 1.17.1 and compare the errors with the expected behavior. Trace how explicitly subclassed Protocol attributes are inferred and validated; done means both examples pass type checking without losing the declared attribute type.