test(taproot): assert the serialized transaction, not just the signature

[BitHighlander]

Supports firmware PR BitHighlander/keepkey-firmware#337.

Why

rc25 shipped a taproot signing path that dropped the witness and the locktime footer on the wire — 70 bytes — leaving a transaction that declares the segwit marker/flag but carries no witness stack and no locktime. The host would have broadcast it verbatim.

This whole suite passed the entire time.

signature and serialized_tx are separate nanopb fields with independent presence flags, and signature was populated correctly throughout. Every taproot test read only that field:

test	assertion	why it missed the bug
test_send_p2tr	(signatures, _)	discarded serialized
test_send_mixed_p2tr_and_legacy	(signatures, _)	discarded serialized
test_send_p2tr_with_change	assertIn(EXPECTED_CHANGE_SCRIPT, serialized)	that scriptPubKey is a phase-1 output byte, transmitted well before any witness, so it survives a truncated suffix

What this adds

assertCompleteSegwitTx() — a strict BIP-144 parse that must consume exactly len(raw). This mirrors Trezor upstream, which funnels every success-path taproot test through assert_tx_matches() → CTransaction.deserialize(). A segwit marker promises witness data, so a dropped witness now runs the stream off the end instead of passing unnoticed. It needs no goldens and no seed knowledge, and it catches the whole bug class rather than this one instance.

It returns the per-input witness stacks, so the tests can additionally assert that a key-path spend carries exactly one 64-byte element and that a legacy input still serializes its empty 0x00 witness.

Each test also pins the full serialization. Those goldens were captured from a fixed-firmware emulator run and, independently, rederived from the tests' own inputs plus the existing EXPECTED_* witnesses — both agree byte-for-byte (153 / 196 / 301 bytes).

Report gate

validate_junit() treated skip as a waiver. That is right for build-flag-gated features (bitcoin-only, zcash-privacy), where a skip genuinely means "not in this build". It is wrong for a capability the build claims to have: every taproot test opens with requires_taproot(), so had that capability regressed, all six would have skipped and the PDF would still have certified a green run — reporting coverage it never obtained.

MUST_RUN_MODULES converts a skip in those modules into a skipped-but-required failure.

Verification

• fixed firmware: 9 passed across test_msg_signtx_taproot.py, test_msg_getaddress_taproot.py, test_taproot_screens.py
• mutation (truncate to 83 bytes — the exact shape that shipped): AssertionError: tx truncated at offset 83: wanted 1 more byte(s) of 83 total
• report gate both ways: taproot passing validates clean; taproot skipping yields six failures (B21–B26) where it previously reported success