fix(protocols): _lookup_next_layer memoises the resolved class on a hit, so a reload leaves it stale #1559

Describe the bug
ProtocolBase._lookup_next_layer writes the resolved class back into the registry on a hit (pcapkit/protocols/protocol.py:2183-2184, registry[proto] = klass). After importlib.reload of the protocol's module, the registry keeps returning the old class. The method's own docstring (:2162-2168) says that memoising the resolved class under proto "would retain a class that importlib.reload then makes stale" (#421, #425, #555).

Reproduction

reg = IPv4.__proto__
k1 = ProtocolBase._lookup_next_layer(reg, TransType.UDP)
importlib.reload(pcapkit.protocols.transport.udp)
k2 = ProtocolBase._lookup_next_layer(reg, TransType.UDP)
k2 is sys.modules['pcapkit.protocols.transport.udp'].UDP   # False

Expected behavior
After a reload, the lookup returns the reloaded class, as the docstring promises. Alternatively, the docstring states that a hit memoises and goes stale after a reload.

System information
Linux, CPython 3.14.7, main at 16fbea054.

Additional context
A parse also mutates the shared registry this way, which is the order dependence #1557 had to isolate in test_dispatch_keys_did_not_move_with_the_modules. ModuleDescriptor.klass already reads sys.modules cheaply (#574), so dropping the write-back may cost little. Measure it before choosing. Found by the #1557 review; I reproduced it myself.