docs update

docs/subsystems/VideoBackend.md

@@ -300,16 +300,16 @@ Today the callback path effectively does this:
 
 1. DeckLink signals completion.
 2. The callback path asks for a new output buffer.
-3. The callback path enters the shared GL section.
-4. The callback path renders the next frame.
-5. The callback path reads it back.
+3. The callback path requests render-thread output production.
+4. The render thread renders the next frame.
+5. The render thread reads it back into the output buffer.
 6. The callback path schedules the next hardware frame.
 
 That path is visible in:
 
 - [OpenGLVideoIOBridge::RenderScheduledFrame](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/pipeline/OpenGLVideoIOBridge.cpp:18)
 
-This couples output timing directly to render work.
+This no longer borrows the GL context from the callback thread, but it still couples output timing directly to render-thread work.
 
 ### Target Model
 
@@ -352,11 +352,11 @@ Recommended default policy for live playout:
 - prefer recency over completeness
 - drop stale capture frames instead of blocking render or output
 
-The current "skip upload if the GL bridge is busy" behavior is directionally correct for live timing:
+The current latest-input mailbox behavior is directionally correct for live timing:
 
 - [OpenGLVideoIOBridge::UploadInputFrame](/c:/Users/Aiden/Documents/GitHub/video-shader-toys/apps/LoopThroughWithOpenGLCompositing/gl/pipeline/OpenGLVideoIOBridge.cpp:11)
 
-But in the target architecture that decision should move out of GL lock acquisition and into an explicit backend-to-render handoff queue policy.
+The next improvement is to make the backend-to-render handoff policy more explicit in telemetry and playout scheduling, rather than treating it as only a render command mailbox detail.
 
 Suggested input metrics: