Here is what we have found so far.

The captured HDR10 output was genuinely 3840x2160 at 23.976 Hz, RGB 10-bit,
confirmed by i915 state and transmitter registers rather than just a setting.
There was no Kodi crash or GPU reset clearly associated with the blackouts.

Some direct-to-TV SCDC captures showed the channel 0 lock dropping and
recovering: 1 -> 0 -> 1. Clock detection and scrambling status remained active.
CED error counters also contained non-zero values. However, other periods with
reported blackouts showed no sampled lock change, so these observations do not
explain every interruption or identify a root cause.

The latest testing changes the investigation significantly. Stable 12.2.1 and
the Intel-10b support test image reportedly fail with automatic refresh-rate
switching enabled and work with it disabled. SDR is affected too, while Dolby
Vision and HDR10 converted to Dolby Vision reportedly work with adjustment on.
This is therefore not an established Nightly-only regression, nor a failure
specific to the HDR10 rendering algorithm. The Intel-10b image has not
demonstrated a fix.

The next useful test is starting Kodi directly at 23.976 Hz with automatic
adjustment disabled and playing the same movie. If that works but switching
from 60 Hz fails, it points towards the transition sequence. If it also fails,
we need to examine the final HDMI mode and its actual transport parameters.
Resolution, refresh rate, output bit depth, colour format and scrambling must
be recorded in each case; HDR10 content does not itself prove a 10-bit link.

We have a much better trigger now, but not a confirmed root cause. The attached
report separates measured facts, tester observations and untested hypotheses.
