fix(corekit): raise ProtocolError for a NumberField negative bit_length (#831)

[JarryShaw]

Closes #831

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry (centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657 per maintainer policy)

What is the purpose of your pull request?

• fix — corrects a defect

---

Description

#829 guarded the eager 1 << length shift in NumberField.__call__; the
sibling shift in __init__ — (1 << bit_length) - 1 — was still open, so
NumberField(length=4, bit_length=-1) raised a bare ValueError instead
of a catchable ProtocolError.

Also closes the second half: __call__'s negative-length guard used to
sit only inside the bit_length-not-supplied branch, so a field with a
fixed bit_length and a callable length resolving negative produced a
different ProtocolError message (template='...-1s', from
FieldBase.length) than one with no bit_length at all
(length=...). The guard now runs unconditionally, so both raise the
same message. No in-tree call site combines the two (verified against
vlan.py's three bit_length fields, which all take positive literals).

New tests in tests/corekit/test_fields_numbers_negative_length.py
(NegativeBitLengthTests), shown failing on stock 5576708d4 before the
fix. coverage run on tests/corekit/ + tests/protocols/application/:
numbers.py stays at 100% (142→144 stmts). The pinned negative-length
assertion in test_http_unit.py is untouched.

[JarryShaw]

GOOD TO GO — cross-review (opus, independent tree, pcapkit.__file__ printed per run) confirms all six load-bearing claims.

One correction, which I re-derived myself: the description undersells the delta. It is not only "a leaked ValueError becomes a ProtocolError". On 3118ed796 a field with bit_length set and a negative-resolving callable length was usable for building:

stock, fresh field:  .length         -> ProtocolError "…template='>-1s'"
stock, same field:   .pack(0xff, {}) -> b'\xff'   and silently sets _length = 1
stock, then:         .length         -> 1          (the incoherence heals itself invisibly)
PR:                  construct+call  -> ProtocolError "…length=-1"

So a pack() that returned bytes now raises. Still the right change: the stock state was self-contradictory, the width pre_process derived came from the value rather than the declared length, and #829 already drew this line for the bit_length-omitted case — this makes the two branches agree.

Unreachable in-tree: the only bit_length= sites are vlan.py:47,49,51, all positive literals.