Maybe add semantical understanding of `assert not TYPE_CHECKING` (similar to `if not TYPE_CHECKING`)?

Background
I'm using a helper type definition from a stubs package in project. I'll call it MyHelperType here (if it matters, it's actually StrOrPromise from django-stubs). We have two deployment settings:

• In development settings, the stubs package is installed. Here, we'd like to always use its definition of MyHelperType (for mypy, and typeguard runtime checks during tests and usage)
• In a production setting, we don't want to require the stubs package, so we just want MyHelperType to be anything that doesn't cause syntax errors, probably a type alias of Any.

I expected this snippet of code work:

from typing import TYPE_CHECKING, Any

try:
    # Helper Type import that may fail in production settings, abusing collections.abc.Sequence for this example
    from collections.abc import Sequence as MyHelperType
except ImportError:
    assert not TYPE_CHECKING
    MyHelperType = Any

but mypy will give these errors:

main.py:8: error: Cannot assign to a type  [misc]
main.py:8: error: Incompatible types in assignment (expression has type "object", variable has type "type[Sequence[Any]]")  [assignment]

I would have assumed that assert not TYPE_CHECKING causes mypy to treat the except-block as if it was guarded by if not TYPE_CHECKING -- mypy does not give errors for this example:

from typing import TYPE_CHECKING, Any

if TYPE_CHECKING:
    # Helper Type import that may fail in production settings, abusing collections.abc.Sequence for this example
    from collections.abc import Sequence as MyHelperType
else:
    MyHelperType = Any

However, this wouldn't give us run-time type checking provided by typeguard.

The current workaround for me is this more verbose/wet approach:

from typing import TYPE_CHECKING, Any

if TYPE_CHECKING:
    from collections.abc import Sequence as MyHelperType
else:
    try:
        from collections.abc import Sequence as MyHelperType
    except ImportError:
        MyHelperType = Any

I may be missing background information or conclusions of past discussions, but to me it seems reasonable for mypy to understand assert not TYPE_CHECKING and treat the block / following statements as if they were guarded by if not TYPE_CHECKING. (I can see that this could be undesirable in other contexts, and that it may be disputable what should happen in case mypy cannot resolve the import.)

Reproduce the two examples and the current workaround in the linked mypy-play cases, then trace how mypy handles TYPE_CHECKING guards and assert statements. Define the desired behavior for assert not TYPE_CHECKING, including assignment checking, and add coverage showing that the proposed pattern works without changing ordinary assert semantics.