BOARD B - THE ORIGINAL SYMPTOM: A CORRUPTED BUILD ARTEFACT
2026-09-13. One observation, not a rate. This is what started the investigation.

======================================================================
WHAT HAPPENED
======================================================================
Our image build copies each component into the rootfs and then re-hashes it
in place. On the second attempt of one image, that check fired:

  BUILD FAILED: /usr/local/bin/<component> in the image is d2547e86...,
                the artefact is 18575ab9...

The build stopped. Nothing corrupt shipped.

======================================================================
WHAT THE DAMAGE WAS
======================================================================
  difference     : ONE byte, at offset 4,021,543 of a 13,735,160-byte file
                   (4 KiB page 981 of the file)
  value          : 0xF3 -> 0x72
  bit pattern    : XOR 0x81 - bit 7 and bit 0, both CLEARED
  source file    : read 7/7 correct, warm and cold
  destination    : persistently wrong ON DISK, 4/4 cold reads agree
  page cache     : held a THIRD, different wrong value, stable 5/5 warm

So a bad page was written back to disk, and at the same time the cached copy
disagreed with the platter. Each regime was internally consistent.

======================================================================
WHAT IT IS NOT
======================================================================
  a script bug     : install(1) from a source that hashes 7/7 correct
  the disk         : ext4 clean; 0 nvme error/reset/timeout lines; 0 EXT4-fs errors
  a standing fault : 30/30 later copies of the same file were byte-perfect
                     (15 to root, 15 to the data tier, each digested cold)
  a bad tarball    : the prior image still verifies against its sidecar
  detectable by HW : there is no ECC. ramoops reports ecc: 0, EDAC registers a
                     class but no controller. A flip here is invisible.

======================================================================
AN HONEST COMPLICATION - THE BYTE OFFSET DOES NOT FIT
======================================================================
Offset 4,021,543 is 7 mod 32: an ODD offset, i.e. the HIGH byte of the 16-bit
word. Every fault we can currently re-verify on either board sits at an EVEN
offset - the low byte.

We are flagging this rather than filing it off, because it matters:

  * It matches the other captures on POLARITY (bits cleared) and on BIT COUNT
    (two bits, never one).
  * It does NOT match on byte lane.
  * It is also a different regime: this corruption reached DISK, so the flip
    could have happened anywhere along the writeback path, not necessarily in
    the same place as a fault caught in resident memory.

One further complication, stated for completeness: our own earlier notes record
a 2026-08-20 fault epoch on Board A at offsets 9 and 11 mod 32 - also odd. That
log no longer exists, so we CANNOT re-verify it and are not resting any argument
on it.

What survives all of this is the weaker but solid claim: faults are confined to
ONE byte lane of the 16-bit word at a time. In no single capture did both bytes
of a 16-bit word go bad together. Which lane it is has varied between capture
epochs, and we cannot explain that.
