RegistryWarning claims a protocol was overwritten with itself when two distinct classes share a qualname #710

pcapkit/foundation/registry/protocols.py:220-223 reports a registry overwrite by repr()-ing both
classes:

incumbent = protocol_registry.get(name)
if incumbent is not None and incumbent is not protocol:
    warn(f'protocol {name} already registered, overwriting {incumbent!r} '
         f'with {protocol!r}', RegistryWarning)

When the two classes are distinct objects that share a qualname, the message says the registry is
overwriting a class with itself. Observed on main today while running
tests/protocols/test_construction_keyword_check_unit.py:

<frozen abc>:106: RegistryWarning: protocol DUMMYPROTOCOL already registered, overwriting
  <class 'tests.protocols.test_construction_keyword_check_unit._protocol_class.<locals>.DummyProtocol'>
  with <class 'tests.protocols.test_construction_keyword_check_unit._protocol_class.<locals>.DummyProtocol'>

The cause is that _protocol_class() is a factory whose local DummyProtocol is a new class object on
every call, so incumbent is not protocol correctly evaluates true and the guard correctly fires — but
a closure-local class's repr() carries only its qualname, so both sides print identically and the
message conveys nothing about what actually changed.

Scope

• Pre-existing on main, from fix(registry): report the protocol-name collision register_protocol hid (#675) #681's guard; not introduced by fix(registry): report the silent schema overwrites, and name what the code-keyed registrars displaced #695. Verified by running that test
  file against main: 22 passed / 37 subtests / 7 warnings either way.
• Not a behavioural defect — the guard's logic is right and the overwrite is real. The defect is that the
  message is unactionable in exactly the case it was added to illuminate.
• This is the "spurious warning" shape fix(registry): report the protocol-name collision register_protocol hid (#675) #681's incumbent is not protocol identity test was added to
  avoid, surviving in the message rather than in the condition.

Suggested fix

Disambiguate the two operands when their repr()s match — include __module__ plus __qualname__, or
fall back to id(), or note explicitly that the incumbent is a distinct object with the same qualname.
Anything that lets a reader tell which class won.

Found while running down #695's first CI failure (which was #702, not this).