iter28b DIAG documented: universal trim=40 breaks IDR (reverted)

Confirmed the 40-byte inflation is non-uniform — IDR slice has correct
size from VAAPI; only P/B slices are inflated. Real fix requires dynamic
rbsp_stop_bit detection or per-slice-type logic.

phase8_iteration27_close.md

@@ -30,6 +30,16 @@ Per kernel iter20 + iter27 printks, with α-25/26/27/28 all in place:
 
 All inspected fields match. Yet libva output diverges at byte 1382401 (frame 2 boundary), 12.2M bytes total differ across 10 frames.
 
+### iter28b DIAG: universal 40-byte trim breaks IDR (tested, reverted)
+
+`LIBVA_HEVC_TRIM_TRAILING=40` was tested as a quick refute/confirm of the 40-byte-inflation hypothesis. Result:
+- libva HEVC 10-frame hash diverged at byte 899745 (INSIDE frame 1, not at frame-2 boundary).
+- Trimming 40 bytes off IDR slice (96890→96850) corrupted frame 1.
+
+Conclusion: the 40-byte inflation is NOT uniform per slice. The IDR (frame 1) slice has correct size from VAAPI. Only P/B slices have the inflation. A real fix requires dynamic detection — scan for rbsp_stop_one_bit, or per-slice-type logic.
+
+Iter28b code reverted: `6646b16`.
+
 ### Likely root cause for frame 2+ (deferred)
 
 The libva OUTPUT buffer for frame 2 = 5552 bytes (= 3 Annex-B start + 5549 from `slice->slice_data_size`). ffmpeg-v4l2request's OUTPUT for the SAME frame appears to be ~5512 bytes (= 3 + 5509, based on its `bit_size = (size+extra_size)*8` formula).