fix(internet): a framed IGMPv3 Report cut inside a record parses a phantom zero-filled record #2756

Describe the bug
An IPv4-framed IGMPv3 Report whose capture is cut inside record 1, with the IPv4 total length still intact, parses with a second, phantom group record. Record 2 was never captured. It is zero-filled to the frame's declared length: type Unassigned, no sources, plus one SchemaWarning: packet length < 0: -4. If the cut falls 21–23 octets in, the phantom has type MODE_IS_INCLUDE. The rebuild is byte-exact, but info.records lists a record the capture does not contain.

Reproduction
The #2755 cross-review confirmed this on main 1b4f9703e, and on #2755's head as well, so it is not new: cut an IPv4 + IGMPv3 Report 4–15 octets into the Report and parse the frame.

Expected behavior
No record past the captured octets. The cut is recorded as a short read, quietly. This is the frame-side counterpart of the #2711 option-2 ruling: that ruling (no zero-fill past the records present) covers standalone Reports, and frames should follow the same intent. Round-trips stay byte-exact.

Additional context
This is blocked until #2755 lands. Both touch the counted-list path in ListField and Schema.unpack.