remove EOL Python versions

The bitmask `setting & 0xFF` truncates the 16-bit setting identifier
to only 8 bits. This silently corrupts any setting ID above 255 during
serialization.

The identifier field in SETTINGS frames is 16 bits wide (RFC 9113,
Section 6.5.1), and `_STRUCT_HL` already uses the `H` format
(unsigned short, 16 bits) for it. However, `& 0xFF` discards the
upper byte.

For the standard settings (0x01 through 0x08) this has no visible
effect since they all fit in 8 bits. But RFC 8701 GREASE values like
0x0a0a or 0x1a1a, as well as any future extension settings > 0xFF,
would be silently mangled on a serialize round-trip.

Change the mask to `& 0xFFFF` to match the actual field width.

GoAwayFrame.serialize_body already masks last_stream_id with
& 0x7FFFFFFF, but parse_body reads the raw 32-bit value without
stripping the reserved top bit. If a peer happens to set that bit,
last_stream_id would be read as a value >= 2^31 instead of the
actual stream ID.

Similarly, WindowUpdateFrame.serialize_body masks window_increment
with & 0x7FFFFFFF, but parse_body doesn't. If the reserved bit is
set, the unmasked value exceeds 2^31-1 and the frame is rejected
with InvalidDataError — even though RFC 9113 Section 6.9 says the
reserved bit "MUST be ignored when receiving."

The rest of the codebase already follows this pattern:
  - Frame.parse_frame_header masks stream_id & 0x7FFFFFFF
  - Priority.parse_priority_data masks depends_on & 0x7FFFFFFF

Add the same mask to GoAwayFrame.parse_body and
WindowUpdateFrame.parse_body for consistency.