fix(internet): an IGMPv3 Report cut in its Additional Data loses the octets on a schema rebuild #2687

Found by the short-read audit, and confirmed by an independent re-probe. This is a sibling of #2662.

The defect: when a capture ends inside an IGMPv3 Report's Additional Data (the octets after the counted records), GroupRecordListField parses those octets as a partial record. Schema.unpack records ('records', n). Report.post_process then trims records to num_group_records and moves the surplus into payload, but leaves the record naming records. Report.pack() therefore keeps part of records and blanks the payload that holds the captured octets, so Schema_IGMPv3.unpack(cut, declared).pack() drops them. The protocol path hides this, and so does the existing test, test_cut_additional_data_goes_to_the_next_layer.

Fix: when post_process re-splits, re-point the built-in record to ('payload', n - consumed).

Test: check at the schema level that unpack(cut, declared).pack() == cut and that from_dict(to_dict()) gives back the captured octets. Cover a declared length equal to the capture and one larger than it, for three cases:

• one record plus extra octets;
• no records plus extra octets;
• additional data long enough to hold a whole record.