Fix movie compositor publication

docs/asset-resolution-re.md

@@ -280,9 +280,12 @@ frame; both still pass with the entire `extracted/` tree physically moved aside
 SC0000's native capture verifies operands `(0x33, 0, 2, 0)` and immediate VM continuation at `0x13d1`.
 In Godot the real site opens the same 8,194,052 VFS bytes, publishes changing 800x600 frames, and retains
 them across pre-yield static surface preparation. The later `0x21c` presentation service remains parked
-until DirectShow EOF, then scene cleanup stops the movie. Manual interactive validation still does not show
-the movie despite those successful lifecycle logs; visible compositor/layer publication is the next bounded
-investigation. The real-scene trace remains a separate extracted-present test
+until DirectShow EOF, then scene cleanup stops the movie. The initial invisible result was compositor-only:
+the static `(assetId,colorKey)` image cache froze the first movie sample, while an extra current-sample
+background copy was covered by the correctly positioned retained movie object. Dynamic movie surfaces now
+bypass that cache and publish only at their retained z-position. A windowed run reached first frame 101 and
+stop frame 190, and manual observation confirmed visible changing video. Movie audio remains intentionally
+unrendered. The real-scene trace remains a separate extracted-present test
 because the current `Paths.Scripts()` test bootstrap still locates its root `*.BIN` fixtures there; migrating
 that test/bootstrap path is unrelated to movie asset loading and was not folded into this slice.
 

docs/engine-re.md

@@ -871,14 +871,15 @@ not itself block the VM. SC0000 prepares additional static layers, then reaches
 service continues sampling the retained movie until DirectShow EOF, after which the following script
 cleanup releases it. The static preparation before `0x21c` is not a movie teardown boundary.
 
-**Manual-test correction (2026-07-11):** the initial port incorrectly treated those pre-yield static loads
-as surface replacement, producing start/first-frame/stop all in render frame 0. The bounded host now keeps
-the movie as an independently updating retained layer, parks `0x21c` until the DirectShow completion event,
-then permits cleanup. A real-render lifecycle run records first frame 98 and stop frame 181. The screenshot
-sequence's known stale-CG/transition behavior can obscure this layer, so screenshot appearance is not used
-as the visual oracle. **Manual recheck remains unresolved:** normal interactive SC0000 logs start, changing
-frame delivery, EOF, and delayed stop, but the movie is not visibly presented in the application. The next
-slice must diagnose compositor/layer publication rather than reopening decode or VM-lifecycle timing.
+**Manual-test corrections (2026-07-11):** the initial port incorrectly treated pre-yield static loads as
+surface replacement, producing start/first-frame/stop all in render frame 0. The bounded host now retains
+the movie through `0x21c` until DirectShow completion. A follow-up compositor trace proved the movie object
+was present at the correct z-position, but the static AGF cache reused the first decoded sample forever
+because every sample has the same `(assetId,colorKey)`. An unconditional current-sample backbuffer copy did
+not help because normal retained composition immediately covered it with that cached first sample. Movie
+surfaces now bypass the static cache and publish only through the retained object. A windowed run records
+first frame 101 and stop frame 190; the user manually confirmed visible playback. The separate lower white
+textbox-area object remains outside this finding, as does the deliberately unrendered movie audio stream.
 
 The `/v2` image names/comments the handler; movie ctor/interface/open/play/volume/release workers; sound
 route helpers; renderer media-type/sample workers; and stop/detach/destructor lifecycle. The image was

docs/phase-a-slice-plan.md

@@ -1226,10 +1226,13 @@ saved. Validation covers the exact real-SC0000 operands and `0x13c8 -> 0x13d1` b
 payload identity, actual 800x600 RGBA DirectShow decode, .NET/Godot builds, and the real Godot site opening
 the same VFS byte count. Manual testing exposed and corrected an initial same-frame teardown: pre-yield
 static loads no longer destroy the movie, `0x21c` waits for DirectShow completion, and a real-render run
-records first frame 98 / stop frame 181. The shot-sequence's known stale-CG behavior can cover the movie,
-so it is not treated as visual proof. **Manual recheck is not visually complete:** the normal application
-logs start, changing frame delivery, EOF, and delayed stop, but shows no movie. Carry compositor/layer
-publication forward as the next bounded diagnostic; do not reopen the proven VFS/decode/resume lifecycle.
+records first frame 98 / stop frame 181. A follow-up compositor-only investigation found that the movie
+object was present at the correct retained z-position, but the static AGF image cache keyed by
+`(assetId,colorKey)` froze its first sample. A duplicate unconditional backbuffer copy of the current sample
+was then covered by that same retained object. Dynamic movie surfaces now bypass the static-image cache and
+publish only through their retained object. A windowed auto-play run recorded first frame 101 / stop frame
+190, and the user manually confirmed that the video visibly played. The known lower white/textbox panel is
+an unrelated retained-object issue. Movie audio remains deliberately unrendered and out of scope.
 The decoder test
 asserts two delivered MPEG frames differ. The two archive/decode tests
 also pass with all of `extracted/` physically moved aside. The real-scene trace is intentionally separate: