Round 17: body-size ruled out; total-size bisect flash (Test A)

RESEARCH.md

@@ -687,3 +687,27 @@ but with R14's body size (0x81000, via the larger R15 U-Boot):
 |---|---|
 | green (persistent) | body size innocent; the 0x1000 offset somehow guilty — re-bisect |
 | black | FIT body > 0x80000 breaks this depthcharge — fix = keep FIT under 512 KiB (minimal FDT subimage) with U-Boot @0x1000 |
+
+## Round 17 — R16 green decodes body-size theory; total-size bisect
+
+R16 (R13 layout, body 0x81000): **green** — body size ruled out (R16
+and R14 share body 0x81000). Updated correlation: total wrapped-image
+size / image_size field: ran ≤ 449772, dead ≥ 453432. Device-era
+sources recovered far enough to rule out boot64/fit_decompress size
+checks (kukui r93/12573-B code identical modulo cosmetics; bounds
+0x5f800000/0x60000000/0x80000000 — kend≈0x4006xxxx passes; the loader
+is DETERMINISTIC: first CB_MEM_RAM range, kstart=0x40000000 — the
+"random 2 MiB slot" note from Phase 1 was mainline behavior, [REVERSED]
+for the device).
+
+### Test A (payload a27f0354…, flashed, cmp+vbutil OK)
+
+R16's exact known-good content (wrapper v1 green, U-Boot @0xB4,
+contiguous — wfi hang expected) + 8 KiB zero tail padding → total
+457964, image_size=457964, body 0x83000. Isolates TOTAL SIZE from the
+0x1000-offset/padding variable:
+
+| observation | conclusion |
+|---|---|
+| green | total size innocent → the 0x1000 alignment padding/placement is the killer (re-test padding content) |
+| black | total size (image_size value) alone gates the handoff |