docs(http): three measurements in _guess_version's #805 comment block are stale since #811 and #799 #824

pcapkit/protocols/application/http.py:358-394 carries a comment block whose measurements #811 and #799 have since invalidated. Three sentences in it are now false, each checked on origin/main (3cbdf8999):

1. :384-387 — "Measured: a 16-octet GOAWAY (b'\x00\x00\x15\x07\x00\x00\x00\x00\x00' + b'\xff' * 7) still raises a bare struct.error through httpv2.HTTP directly." That exact input now raises ProtocolError: Field debug resolved to a negative length; template='-1s', because fix(fields): raise ProtocolError, not struct.error, on a negative resolved field length #811 converts it in FieldBase.length.
2. :387-394 — "Closing that class needs the fix at its actual root — a negative field length raising ProtocolError in Schema.unpack / FieldBase.length instead of the bare warning those currently emit … tracked as corekit: a negative field length only warns in Schema.unpack, instead of raising ProtocolError #805 rather than attempted here." fix(fields): raise ProtocolError, not struct.error, on a negative resolved field length #811 did exactly that, so "currently emit" and "rather than attempted here" describe closed work.
3. :367-368 — "HTTP(io.BytesIO(b'\x00' * 8), 8) raised a bare struct.error" now gives ProtocolError: unknown HTTP version, per httpv2: the frame guard tests the declared length, not the buffer, so a 4-octet frame can report length=16777215 #799's guard.

Found by #823's cross-review and confirmed by me. #823 deliberately left it alone — fixing prose in pcapkit/ turns a test-only PR into a code PR with different risk — which is right, but it needs its own change or it will not happen.

The fix is a comment repoint, no behaviour change. Worth re-measuring each claim as it is rewritten rather than deleting them: the block explains why the HTTP/2 arm is shaped as it is, and that reasoning is still load-bearing even where its numbers moved.