Use standard NMEA2000 3/5 fast-packet split + re-enable sequence check

[kaanow]

What

Switch the fast-packet control-byte split from 4/4 (nibble) to the standard
NMEA2000 3-bit sequence counter + 5-bit frame index, and re-enable the
sequence-integrity check that was disabled because of the old split.

Why

XanbusMessage.append_bytes currently reads sequence_id = b0 >> 4,
frame_id = b0 & 0x0F. The NMEA2000 fast-packet spec is seq = b0 >> 5,
frame = b0 & 0x1F.

The two are indistinguishable for messages of ≤16 frames (the frame index's
high bit stays 0), which is why most PGNs decode fine. But PGN 0x1F0BE
("MPPT Data") exceeds 16 frames — and at frame 16 the frame index's bit 4
flips and, under the nibble split, leaks into the sequence id (and can make
frame 16 look like a fresh frame-0). That's exactly why the sequence check is
currently commented out:

# Disabled for now, that won't work for PGN 1f0be since it'll send packets that
# are larger than 16 chunks

With the spec-correct 5-bit frame index, the sequence id is stable across all
frames, so the integrity check is safe to re-enable for every PGN including
0x1F0BE — rejecting partially-missed / interleaved messages instead of blindly
concatenating them.

Test

Adds test_fastpacket_reassembly.py, which synthesises a 22-frame (>16)
message and checks:

1. XanbusMessage (with this change) reassembles it correctly;
2. the same frames trip the integrity check under the old 4/4 split (the bug);
3. a ≤16-frame message still reassembles (no regression).

payload=150B -> 22 frames (>16)
PASS: XanbusMessage (3/5) reassembles the 22-frame message correctly
PASS: 3/5 reference completes and matches payload
PASS: 4/4 nibble reference fails on the same frames (bogus=True)
PASS: <=16-frame message still reassembles (no regression)
ALL TESTS PASSED

Scope / honesty

The test exercises the reassembly logic on synthesised frames. It does not
prove that a real Conext 0x1F0BE uses the 3/5 encoding — only that a >16-frame
fast-packet message requires a ≥5-bit frame index (4 bits can't count past 16),
so the 4/4 split cannot be correct for it, and that the code now handles the
standard layout. I don't have a >16-frame 0x1F0BE capture to verify against
(the install I tested on emits a 9-frame 0x1F0BE), so a check against your
hardware would be very welcome.

For what it's worth, I arrived here while validating your PGN layouts against a
second Conext system (SW 4024 + MPPT 60 150): both splits decode the short PGNs
127172/127173 identically, and battery voltage matched Modbus ground truth
(26.5 V, r=0.98) — so those layouts are confirmed on independent hardware. Thanks
for berrybms; it was the key that unlocked our decode.