dispatch: warn/error on indistinguishable parametric ABC multimethods

[Technologicat]

Context

The runtime type checker now does best-effort element checking for parametric abstract ABCs (Iterable[T], Collection[T], Reversible[T]). Elements are checked when the value is Sized (concrete collection); for opaque iterators, only the ABC is checked.

This means registering e.g. Iterable[int] and Iterable[float] as separate multimethods works correctly for concrete collections (the dispatcher can distinguish them by checking elements), but is ambiguous for opaque iterators (both match on ABC alone, most-recently-registered wins).

Similarly, Iterator[T] and Container[T] always ignore type args, so registering multimethods that differ only in those type args is always ambiguous.

Proposed improvements

1. Warn when a type arg is silently ignored during dispatch — specifically for Iterator, Container, and the opaque-iterator fallback path of Iterable/Collection/Reversible.

2. Raise TypeError at registration time when registering multimethods that are indistinguishable for non-Sized values (same origin, different type args, where element checking can't be guaranteed).

Difficulty

The tricky part is defining "indistinguishable" precisely when checkability is value-dependent. For Iterable[int] vs Iterable[float], concrete collections are distinguishable but opaque iterators are not.

Split out from D5 in TODO_DEFERRED.md (typecheck-layer part resolved in the same commit that added TypedDict and Protocol support).