test(7.15): reconcile the branch with what rc29 actually pins, plus the chain_id regression - #212

…t's scope

The PDF is the artifact a release review actually reads, and it was quietly
claiming more than it knew. Two defects, one visible consequence.

parse_junit only emitted a 'mod::meth' key when the JUnit classname contained
a dotted test_msg_*/test_sign_*/test_verify_* module. Native gtest suites carry
a bare classname ("Dice", "Storage"), so they produced no such key, and _lookup
has no bare-method fallback by design. CI merged the firmware-unit XMLs into the
report input and every one of the 432 native tests was then structurally
impossible to reference from SECTIONS. Bare classnames are now keyed as
'Suite::Test'.

The header reported "N/N PASSED" against the catalog with nothing saying the
catalog is a subset. A 7.15 RC audit grepped this PDF for feature keywords,
found no hits for dice and PIN KDF, and reported both as having zero coverage.
Both had in fact run green in the same CI run: test_reset_device_dice passed,
and so did all five Dice unit tests and the PIN KDF rewrap tests. The header now
states catalogued-vs-executed and says outright that absence here is not
evidence of absence.

New section K catalogues what that audit went looking for: the dice flow
end-to-end (digest equals SHA256 of exactly the injected rolls, then the
mnemonic is derived from post-mix internal entropy, which is what proves the
rolls reached the seed), the aborted-reset EntropyAck disarm regression, the
five Dice known-answer and independence vectors, and the v16->v19 PIN KDF
rewrap plus storage migration.

Verified against the 7.15.0 RC artifacts from run 31284108490: dice went from 0
to 13 occurrences in the rendered PDF, section K renders 11/11 passed, and
poisoning Dice::MixDependsOnRolls in the merged JUnit turns the header red and
fails --validate-junit, so the entries are wired to real results.

Needs the companion firmware change: the CI trigger validated against the
Python JUnit alone, where every native entry resolves to "missing".

Chasing a rendering defect on the per-output shielded confirm turned up
something worse than a missing screenshot: ZcashSignPCZT is never sent to a
device anywhere in this suite. Every test in test_msg_zcash_sign_pczt drives
a ScriptedTransport with canned responses -- they are offline contract tests
that prove the client builds and orders its messages correctly, and prove
nothing whatsoever about firmware behaviour.

The device-driven Zcash tests cover transparent signing, display-address,
FVK derivation and the seed fingerprint. None of them signs a shielded
output. So the on-device shielded path -- including the confirm screen that
fsm_msg_zcash.h designates as the verification gate for Orchard output
values, since total_amount is "a summary prompt" taken from the host -- has
no automated coverage at all.

The catalog gave no hint of this. The section Z entries read exactly like
the device tests around them, and that is how a screen nobody has ever
rendered sat behind seven green checks.

Say it in the entry instead. No screenshot hint: requesting frames from a
test that cannot reach a device would produce silently zero of them, which
is the same class of empty-but-green evidence this whole pass exists to
remove.

Verified: --screenshot-filter does not select it, and the report still
renders 325 tests and passes --validate-junit against the RC artifacts.

ZcashSignPCZT had never been sent to a device by anything in this suite.
Every test in test_msg_zcash_sign_pczt drives a ScriptedTransport with canned
responses; the device-driven Zcash tests cover transparent signing,
display-address, FVK derivation and the seed fingerprint. So the on-device
shielded path had no automated coverage at all, and seven green checks in
section Z read exactly like device coverage while proving only that the
client serialises its messages in the right order.

That is how a confirm screen which cannot physically fit its amount line
shipped unnoticed. The per-output shielded confirm is the verification gate
for Orchard output values -- total_amount on the summary prompt is taken
straight from the host message -- and a unified address is 106 characters,
three full body rows, against a three-row body. The amount never rendered.

The fixtures are the firmware's own known-answer vectors from
unittests/firmware/zcash.cpp, so the device's cmx recomputation accepts them
without needing a Pallas implementation in Python. The same note under both
pools commits to a different value, which is what makes the pool tests
possible at all.

Four tests:
  - the output review is two screens, and they render differently and
    non-blank (read_layout returns a framebuffer, not text, so the assertions
    are structural rather than OCR)
  - a one-bit change to the recipient breaks the commitment
  - the Orchard commitment is refused when Ironwood is declared
  - the Ironwood commitment for that same note is accepted

Two gates the offline fixtures do not satisfy had to be met for real
firmware: the header digest is recomputed and compared, and for a
shielded-only transaction the verified fee reduces to orchard_value_balance
and must equal the declared fee. Both are computed here rather than canned.

VERIFIED AS A REGRESSION TEST, not just written: run against the shipped
7.15.0 RC emulator (docker image from run 31284108490, the 27970b0c6 build)
it fails with "expected 2 ConfirmOutput screens, got 1", while the
commitment-binding and pool-selection tests pass. It reproduces the defect on
the firmware that has it.

Catalogued as Z22-Z25 with screenshot hints, so the shielded confirm screens
finally appear in the report -- the RC run captured 1037 OLED frames and not
one came from a shielded flow.

The firmware test was renamed PinKdfV16RewrapsToV19AfterCorrectPin ->
PinKdfRewrapsToActiveVersionAfterCorrectPin when the STORAGE_PIN_KDF_V19 gate
went to 0, because it is no longer v19-specific: it now asserts BOTH sides of
the gate, which is what makes it meaningful in the shipping build where v19 is
off. Catalog validation failed against the old name.

Adds K8b for PinUnlocksAfterRebootUnderV17, the end-to-end create/set-PIN/
serialize/reload/unlock/decrypt regression. It belongs in a curated catalog
precisely because every other storage test stays in RAM, and the wallet lockout
it guards lived on the serialize/reboot boundary.

Firmware fix ed6db167 shipped without a test at a chain id that reproduces it.
Every EIP-1559 case in this file uses chain_id 1 or 3 — both single-byte — so
the bug had zero coverage in the file that tests the feature.

hash_rlp_field((uint8_t*)&chain_id, 1) fed only the least-significant byte into
keccak on little-endian ARM. Base (8453 = 0x2105) hashed 0x05 and the signature
recovered to an unrelated address. RLP length was correct; the legacy EIP-155
path was correct; only the EIP-1559 hash was wrong.

A golden r/s needs a device run, so this is a differential: sign one identical
tx under 8453 (0x2105) and 4357 (0x1105). Same low byte AND same RLP length
header, so broken firmware hashes an identical pre-image and — signing being
deterministic — returns the same signature twice, failing the assertion. Fixed
firmware hashes 0x21 0x05 vs 0x11 0x05. No golden value, no new deps (the repo
has ecdsa but no keccak, so recovering the signer address was not available).

Version-gated to 7.15.0 so it SKIPs rather than fails on older firmware.

[1] Version gate removed real reset coverage. My requires_firmware("7.15.0")
skipped the WHOLE of test_reset_device_pin / test_failed_pin on the 7.10
emulator — PIN entry, EntropyRequest/Ack, and mnemonic derivation checked
against a locally computed expected value — to silence one assertion. Branch on
the version instead: pre-7.15 acks the Internal Entropy ButtonRequest that
legitimately still exists there, then both paths converge on
PinMatrixRequest. Everything downstream keeps running on every firmware.

[2] Z17 claimed 'ZcashSignPCZT is not sent to a device anywhere in this suite
... no automated coverage at all' while 3bbf996 in the same branch added
exactly that device test. Scoped the claim to THIS module and pointed at Z22.
Notable because the comment above the scope block explains that saying so is
'the difference between evidence and a misleading completeness claim'.

[3] The report said CI 'executed' JUNIT_CENSUS['ran'], which increments for
every collected testcase including skips. The run behind this PR was 613
collected / 252 skipped — the report would have overstated execution by 41%,
and a version-gated test that SKIPs on an old emulator is not evidence the
feature works. Track skipped separately and say 'collected', with the skip
count and why skips happen stated inline.

[4] _capture_button_screens read the framebuffer BEFORE delegating to the
original callback, which is where the render-settle delay lives — so it could
capture a partially drawn or previous screen. Reading after would be worse
(the original presses the button and advances). Settle inside the wrapper
before reading. Unconditional, unlike client.callback_ButtonRequest's
SCREENSHOT-only sleep, because these are structural assertions rather than
screenshot evidence and need a settled layout on every run.

[5] handled in the PR description.