fix(ipv4,tcp): a header length declared past the data zero-fills the missing octets on rebuild #1404

Describe the bug
When an IPv4 ihl or a TCP data offset declares more header than the captured data holds, and the option area starts at or past the end, the missing octets are zero-filled. The rebuilt frame is longer than the captured one. This is a declared header length, separate from #1325's option lengths; #1398 pins the end-of-options case deliberately (test_an_option_area_declared_past_the_data_still_ends_at_eool) but asserts no round trip.

To Reproduce

• Ethernet + IPv4 with ihl=6 and only 20 header octets present: Ethernet.from_data(Ethernet(raw).info) gives 34 octets in and 38 out.
• The TCP equivalent gives 69 in and 74 out.
• Identical on main, and at fix(protocols)!: a declared length running past the data is accepted and zero-filled on rebuild #1398's head bc5d90f7b.

Expected behavior
Byte-exact, per the every-round-trip ruling: keep the short header as captured (Raw inside the parent), as #1325 does for options.

Found by the #1398 cross-review. Blocked until #1398 merges, which touches the same option-area code.