pub(super) fn build_footer_flag_notes() -> Vec<String> {
    vec![
        "Cross-save q/p traces now also split those two mixed residual classes by footer and span behavior: 0x000055f3/0x0001/0xff always carries short-flag pair 0x01/0x00 on a fixed span-0x03 tunnel-dominant family, while 0xff0000ff/0x0001/0xff always carries short-flag pair 0x00/0x00 on the scattered-span TrackCap-dominant outlier family. The remaining unknown is therefore the meaning of those short-flag families and the sparse branch that routes a minority of tunnel rows into the 0xff0000ff outlier class.".to_string(),
        "Direct consumers of those footer bits are grounded now too: bit 0x20 of [child+0x20] is the admission gate into the 0x00528d90 branch when no caller/global override is present, while bit 0x40 only feeds the later 0x00529730 -> 0x530280 follow-on. Since both mixed residual classes keep the second footer byte at zero in q/p, the remaining split is now specifically the first footer byte / bit-0x20 gate rather than both footer bytes.".to_string(),
        "That bit-0x20 gate is no longer floating without context either: the 0x005295f0..0x005297b7 consumer strip repopulates candidate cells through 0x00533ba0, walks child lists through 0x00556ef0/0x00556f00, and honors the same controller mode byte [owner+0x3692] that the atlas already places under the world-window presentation dispatcher. The next infrastructure pass should therefore treat the remaining bit-0x20 question as a nearby-presentation/controller owner problem, not as a serializer-only problem.".to_string(),
        "That owner family is layout-state specific now too: the surrounding helpers sit on atlas-backed layout/presenter roots, with 0x00548da0 walking layout list root [layout+0x2593] and 0x0054bab0 mutating layout slots [layout+0x2637/+0x263b/+0x2643]. So the remaining bit-0x20 split is increasingly a layout/presentation admission question above the infrastructure seam, not a simulation-owned route or rebuild question.".to_string(),
    ]
}
