Round 16: bisect R14/R15 no-handoff — body-size vs U-Boot-offset

RESEARCH.md

@@ -664,3 +664,26 @@ Maximally distinguishable phases:
 | blink train repeating periodically | reset loop (WDT) — identify the phase by the colors that flicker |
 | magenta + orange/blue/red/yellow bands | crash in the next window after the last band |
 | banner on black | success |
+
+## Round 16 — bisecting the R14/R15 handoff failure
+
+R15 (`b1c5c380…`): nothing at all — no magenta, no blink train. Since
+the wrapper + header bytes at 0x40 are functionally identical across
+R13 (ran) and R14/R15 (did not run), the failure is depthcharge-side.
+Only depthcharge-visible structural change between R13 and R14: the
+mkdepthcharge body grew from 0x80000 to 0x81000 when the 4 KiB
+alignment padding landed (R15: 0x82000). Verified the device-era
+depthcharge (R93, `0.0.22-10566-g8417b00957`) sources are not locally
+available (clone is mainline-only; googlesource fetch failed); mainline
+KERNEL_SIZE is 0x20000000, so a 512 KiB constraint has no known
+mechanism yet — but the correlation is 2-for-2.
+
+### Discriminating flash (payload `d418252a…`)
+
+R13 layout exactly (wrapper v1 = green fill, no blinks, U-Boot @0xB4)
+but with R14's body size (0x81000, via the larger R15 U-Boot):
+
+| observation | conclusion |
+|---|---|
+| 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 |