fix(fields): NumberField leaks a bare ValueError on a negative resolved length, before FieldBase.length sees it

[JarryShaw]

A bare builtins.ValueError escapes NumberField on the most common negative-length schema shape — the same class of defect #805 set out to eliminate, and one that neither #811's guard nor #827's refinement can see, because it fires before FieldBase.length is ever consulted.

NumberField.__call__ sets self._bit_length = self._length * 8 and then evaluates 1 << self._bit_length whenever bit_length was not supplied. With the shape used at pcapkit/protocols/schema/internet/hip.py:734 — NumberField(length=lambda pkt: pkt['len'] - 4, signed=False) — measured on 3.14:

len= 8 -> resolved= 4  template='>I'   .length=4
len= 4 -> resolved= 0  template='>0s'  .length=0
len= 3 -> resolved=-1  ValueError: negative shift count   is BaseError=False
len= 0 -> resolved=-4  ValueError: negative shift count   is BaseError=False

is BaseError=False is the problem: a caller cannot catch this as a pcapkit error, which is exactly what #805/#811 were about. A truncated or malformed len field on the wire is enough to trigger it.

Same live shape at hopopt.py:722, hip.py:758, :760, :823, :1325, :1338, and ipv6_opts.py:727.

The fix belongs where the shift happens — validate the resolved length before computing bit_length, and raise ProtocolError from pcapkit.utilities.exceptions naming the field and the resolved value, consistent with what FieldBase.length now does for a negative template.

Found by #827's cross-review while checking that PR's regex, and reproduced here independently. Worth noting that #827's docstring reasoning surveys "every template this package builds from a resolved field length" and walks past this path, since it never reaches a template at all.

[JarryShaw]

Correcting this issue's own call-site list — five of the eight I cited do not carry the shape. Found by #829's author, verified by me against origin/main:

hip.py:734   NumberField(length=lambda pkt: pkt['len'] - 4, ...)          subtraction: yes
hip.py:758   NumberField(length=lambda pkt: (pkt['len'] - 4) // 2, ...)   yes
hip.py:760   NumberField(length=lambda pkt: (pkt['len'] - 4) // 2, ...)   yes
hip.py:823   NumberField(length=lambda pkt: pkt['pub_len'], ...)          NO
hip.py:1325  NumberField(length=lambda pkt: pkt['len'], ...)              NO
hip.py:1338  NumberField(length=lambda pkt: pkt['len'], ...)              NO
ipv6_opts.py:727  NumberField(length=lambda pkt: pkt['len'], ...)         NO
hopopt.py:722     NumberField(length=lambda pkt: pkt['len'], ...)         NO

So the reachable set is three sites, not eight — hip.py:734, :758, :760, all of which subtract a fixed header size from a wire length and so go negative when that length is short. The other five pass a wire length straight through; since those fields parse as unsigned, they cannot themselves resolve negative, and they are not instances of this defect.

That does not change the defect or the fix — the bare builtins.ValueError: negative shift count was real and is what #829 addresses — only its blast radius, which I overstated.

Why I got it wrong, since it is a repeatable mistake: I relayed the citation list from #827's cross-review without checking each entry, because the finding itself had already reproduced. An agreeing claim's file:line list needs the same verification as a disputed one — a correct conclusion does not make its supporting citations correct.