IPv6Address.__eq__ and __hash__ fold in the interface scope_id, but IPv6Address inherited the scope-blind _BaseAddress.__lt__. Under @functools.total_ordering — which derives > from < and == — that made ordering inconsistent for addresses differing only by scope: both a > b and b > a could be true, so antisymmetry broke and sorted()/min()/max() were non-deterministic for scoped addresses.

This adds a scope-aware IPv6Address.__lt__ that tie-breaks on scope_id only when the integer address is equal (unscoped sorts before scoped; scope ids compare lexicographically). Because the derived operators dispatch through type(self).__lt__, overriding only __lt__ routes all four comparisons through the scope-aware path — which also repairs scoped IPv6Interface and IPv6Network ordering, since they delegate to address comparison. _BaseAddress.__lt__ is left untouched, so IPv4Address is unaffected.

Verified on a 3.16.0a0 build and on stock 3.14.6: without the fix, antisymmetry fails and the three scoped permutations of one address yield 6 distinct sort orders; with it, ordering is total and deterministic. The new testScopedAddressComparison covers trichotomy, antisymmetry, and stable sorted()/min()/max() for scoped IPv6Address, IPv6Interface, and IPv6Network, with an IPv4 ordering guard.

• Issue: IPv6Address ordering is scope-id-blind, breaking trichotomy and making sorted()/min()/max() non-deterministic for scoped addresses #151769