examples/captures/pcapng.txt records `packet -> NIL` for four blocks that now carry octets

[JarryShaw]

examples/captures/pcapng.txt is a committed tree-format dump of examples/captures/dhcp.pcapng, regenerated by hand from examples/legacy_smoke/Makefile:

##   pcapng.txt                    <- test_pcapng.py,    from ../captures/dhcp.pcapng

Four of its lines are now stale. #646 restored the captured octets that every PCAP-NG packet block was dropping, so the frame-level packet field of each Enhanced Packet Block carries 314 or 342 octets where the committed reference still records none:

$ grep -n 'packet  -> NIL' examples/captures/pcapng.txt
14:  |-- packet  -> NIL      <- Section Header Block, correctly empty
41:  |-- packet  -> NIL      <- Interface Description Block, correctly empty
172:  |-- packet  -> NIL     <- Frame 1, now 314 octets
311:  |-- packet  -> NIL     <- Frame 2, now 342 octets
442:  |-- packet  -> NIL     <- Frame 3, now 314 octets
                             <- Frame 4, likewise

Lines 14 and 41 are right and stay right — those block types carry no captured octets. The four frame-level ones are the drift.

Nothing asserts on this file, so no test went red; it is a reference a human reads, and a reference that disagrees with the code is worse than no reference.

Why it was not fixed in #683

Two reasons, both deliberate:

1. examples/captures/ was outside that change's file ownership.
2. The sibling examples/captures/out.* files already carry unrelated, pre-existing drift against what the tree produces — whole frames differing in payload content, and a protocol -> NIL that now reads 5001. Running the legacy-smoke Makefile regenerates all four together, so refreshing pcapng.txt in passing would have swept that unrelated drift into a PCAP-NG payload fix and made both unreviewable.

Suggested fix

Regenerate pcapng.txt on its own, deliberately, and decide separately what to do about the out.* drift — which wants its own issue, since it predates #646 and has a different cause.

cd examples/legacy_smoke && TZ=UTC python test_pcapng.py

Note the timezone: examples/legacy_smoke/README.rst records that the PCAP three were generated at UTC-05:00 and pcapng.txt at UTC, so regenerating under a different zone would add timestamp churn on top of the payload change.

[JarryShaw]

Measured against this file while fixing #678 (PR #699, which changes how a truncated PCAP-NG parses):
#699 does not move this fixture further. Reporting it here rather than regenerating, as the issue
asks.

Method — the fixture regenerated the way examples/legacy_smoke/test_pcapng.py does, into a scratch
path so the committed file was never touched, once with f0999858e checked out and once with #699's
two source files in place, then diffed against each other:

TZ=UTC python -c "... pcapkit.extract(fin='examples/captures/dhcp.pcapng',
                                      fout='<scratch>/pcapng-regen.txt',
                                      format='tree', verbose=True)"

• f0999858e regeneration vs fix(pcapng): stop a negative length reaching a read on a truncated capture (#678) #699 regeneration: byte-identical (diff exits 0).
• committed examples/captures/pcapng.txt vs either regeneration: the same 116-line diff, which
  is exactly the drift described above — the four frame-level packet -> NIL lines now carrying
  their octets, plus one protocol -> NIL at line 94 now reading 67.

So the drift is unchanged in both content and size, and the cd examples/legacy_smoke && TZ=UTC python test_pcapng.py fix in the issue body still applies verbatim after #699 lands.

That is the expected result rather than a lucky one: #699 only changes what happens when a capture is
cut short of what its blocks declare, and dhcp.pcapng is whole. The untruncated file parses to the
same 4 frames before and after, with the same single ExtractionWarning: EOF reached and nothing else.