[Bug] Crash the render and rhi thread accessing the same the rhi command list

[Winteradio]

[Winteradio]

Summary

RHIFrameExecutor and FrameGate have a initialization mismatch that causes the Render thread
and RHI thread to concurrently access the same RHICommandList instance.
The result is a data race: intermittent crash or corrupted rendering.

---

Root Cause

RHIFrameExecutor is initialized as:

m_beginIndex  = frameCount - 1  // = 2
m_endIndex    = frameCount - 1  // = 2
m_recordIndex = 0

beginIndex == endIndex means Execute() sees an empty range — correct at startup.
However, endIndex wraps PAST beginIndex after the first Submit:

Frame 1 Submit: endIndex 2 → 0
Frame 2 Submit: endIndex 0 → 1

Execute() range is now [beginIndex=2 .. endIndex=1) in the ring buffer,
which covers: slot[2] → slot[0]

slot[2] was NEVER legitimately submitted — it is a phantom slot
created by the offset between beginIndex(2) and the first real Submit.

---

Collision Scenario (concrete trace)

Init:    begin=2, end=2, record=0, frameDiff=0, frameLimit=3

Frame 1: Acquire slot[0] (record→1), Submit → end: 2→0
         Gate.Submit → frameDiff: 0→1, notifies RHI

Frame 2: Acquire slot[1] (record→2), Submit → end: 0→1
         Gate.Submit → frameDiff: 1→2, notifies RHI

RHI:     Gate.Acquire → frameDiff: 2→1
         Execute(begin=2, end=1)
          └─ now=2 → ExecuteAll(slot[2])  ← begins READING slot[2]

Frame 3: Gate.Submit check: frameDiff=1 < frameLimit=3 → NOT BLOCKED
         Acquire slot[2] (record: 2→0)    ← begins WRITING slot[2]

RESULT:  RHI is executing slot[2] while Render is recording into slot[2].
         DATA RACE → undefined behavior (crash or silent corruption).

---

Why FrameGate Cannot Prevent This

FrameGate only tracks frameDiff (submitted but not yet executed frame count).
At Frame 3, frameDiff=1 which is well within frameLimit=3, so it passes freely.

FrameGate has no knowledge of beginIndex=2 creating a phantom execution slot.
The two subsystems are decoupled — FrameGate cannot compensate for the internal
state mismatch inside RHIFrameExecutor.

---

Intermittency

The race is timing-dependent on OS thread scheduling:

Case A (RHI faster): slot[2] ExecuteAll completes before Frame 3 Acquire
                     → no crash, but slot[2] was empty/garbage → broken render
Case B (Render faster): slot[2] write and ExecuteAll overlap
                        → DATA RACE → crash or memory corruption

---

Fix

Initialize all three indices to 0:

m_beginIndex  = 0    // was: frameCount - 1
m_endIndex    = 0    // was: frameCount - 1
m_recordIndex = 0

begin == end == 0 still satisfies the empty-range invariant.
After Frame 1 Submit, end becomes 1, Execute range is [0..1) = slot[0] only.
The phantom slot at index 2 no longer exists.

With correct init, FrameGate's ordering guarantee holds:
Render: record(slot[N]) → Submit(slot[N]) → Gate.Submit()
RHI: Gate.Acquire() → Execute(slot[N])
Gate.Submit happens-before Gate.Acquire, so slot[N] is always fully written
before RHI reads it. No phantom slot breaks this chain.