fix(enr): handle short port values without throwing

[nflaig]

What changed

• normalize ENR port bytes before getProtocolValue() reads them
• accept valid one-byte and two-byte big-endian port values
• return undefined for empty, zero, or oversized port values instead of throwing
• keep low ports produced by the existing setters usable by getLocationMultiaddr()
• add ENR-level regression tests and direct coverage for discv5's getSocketAddressOnENR() path

Why

A mainnet Lodestar v1.45.0 node using @chainsafe/enr@6.0.1 and @chainsafe/discv5@12.0.1 received a signed remote ENR with a short udp value. During session establishment, getSocketAddressOnENR() accessed enr.udp, and getProtocolValue() threw:

uncaughtException: Encoded protocol length should be 2
at getProtocolValue
at get udp
at getSocketAddressOnENRByFamily
at getSocketAddressOnENR
at SessionService.onEstablished

ENR ports are big-endian integers, so one-byte values are valid. Invalid values received from untrusted peers should make the ENR non-contactable rather than escape as an exception.

This follows up on the normalization added in #333 and applies it to the direct port getters used by discv5.

Related: ChainSafe/lodestar#7445, ChainSafe/lodestar#9310.

Impact

Valid compact ports now decode correctly. Empty, zero, and oversized values are ignored without disrupting the discv5 session service. Normal two-byte ports are unchanged.

Validation

• pnpm build
• pnpm lint (passes; two existing warnings outside this change)
• pnpm check-types
• pnpm test:unit — 28 ENR tests and 65 discv5 tests pass
• pnpm test:e2e — 5 tests pass

[wemeetagain]

maybe this should return the number (eg do the bitshift + add)