Port boot_integrity to Rust, and pin it with two real fixtures

[Zenofex]

Follows #17/#18. The engine learned to read what the bootloader actually verified (BootIntel.com@fd96903); until the CLI does too, the offline verdict says "I cannot tell whether images are checked" about captures that answer the question themselves, and the two implementations disagree about the same device.

What the CLI now reports

  confirmed  Image verification
      The bootloader checked the image before booting it, using a legacy uImage CRC,
      and the check passed. That proves the image was not corrupt. It is not a
      signature: anyone who can write the image can recompute the checksum, so this
      stops bit-rot rather than an attacker.
      read from Verifying Checksum ... OK

  exposed    Secure boot anchor
      The SoC reports the HAB fuse is not enabled, so the boot ROM will run an
      unsigned image. Whatever the bootloader does about checksums afterwards is
      advisory: the chain has no anchor.
      read from hab fuse not enabled

A passing checksum is confirmed, never hardened. Only a verified signature (sha256,rsa2048:dev+ OK) is hardened. The anchor entry is emitted without needing a printenv, since the fuse fact does not depend on one.

The fixtures are the point

Neither is synthetic:

Fixture	Source	What it pins
hab-unblown.log	bootintel-7 lines 1-45	prompt reached with no environment, unblown HAB fuse, and a harness line quoting 'Bad Linux ARM64 Image magic!' that must not trip the anchored failure pattern
verified-image.log	bootintel-20 lines 55-160	environment provable only retroactively, plus a failed check (Bad Magic Number, from an operator's iminfo) and a passed one in that order

Both implementations reproduce expect.txt byte for byte across five fixtures. That is the first time the guarantee has covered anything but a synthetic capture and two environments.

A bug found while porting

The engine's signature pattern included ## Checking (hash|sign), and U-Boot's ordinary FIT output is ## Checking hash(es) for FIT Image at .... Every device using unsigned FIT hashes would have been reported as having had a signature verified, and the verdict would have told a client authenticity was established. No corpus log prints that line, which is exactly why it survived review: absence of evidence read as correctness. The real tell is the algorithm list, so that is what both sides key on now, with a test for each shape.

Breaking, library only

boot_chain::assess returns an Assessment { session, integrity, verdicts } instead of a tuple, and verdict takes the integrity alongside the session. The alternative was a second entry point for the same operation; two functions differing only in how much they tell you is worse for whoever reads it next. No CLI flag, output or exit code changed. verdict --json gains a boot_integrity object mirroring the engine's key names, omitting fields the capture said nothing about rather than emitting nulls.

Under the policy at the top of CHANGELOG.md that puts the next release at 0.9.0.

Verification

• cargo test --workspace: 349 passed, 0 failed
• clippy --workspace --all-targets -- -D warnings and fmt --check: clean
• Engine side green at 418 passed in ci-api-regression, pushed and deployed
• Ran the built binary against both new fixtures

🤖 Generated with Claude Code