[miguel-heygen]

What

After a WebGL context is lost and restored, every graded clip is graded again, including a clip that came on screen while the context was gone.

Why

On loss the runtime marks its entries lost, and on restore it rebuilds the programs of the entries it still has. A graded clip that became visible during the loss tried to build an entry on a dead context, got none, and was never revisited: it reported "WebGL unavailable" and showed ungraded until some later scan, which does not run for a paused playhead. Restore now runs the same scan that creates entries from the data-color-grading attribute, so every shown graded clip gets one.

Reproduced in headless Chrome on a project with three graded clips, calling WEBGL_lose_context loseContext(), seeking to the second clip while lost, then restoreContext(): the second clip stayed "WebGL unavailable" before the change (also at the next seek) and is "Shader active" after.

Test plan

• New test in colorGrading.test.ts: a clip shown while the context is lost has no entry; after the restore event both clips are active. It fails on main and passes here (104 tests in the file pass).
• Real Chrome repro above, before and after.

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 155 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

Unstable (1)

• seqplainkeys-none-center-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE · 0 blocker · 1 important · 0 nits · head 4950fdc3

• important: the Comments ratchet is red on this head because the fix adds a comment line to colorGrading.ts:3870 (43/4247 lines vs 42/4245 at the base). It isn't a required check, so it doesn't gate the merge. Dropping that comment line, or putting the reason in the test name (it's already there), turns it green.

Scope

Calling refresh() on restore is the same idempotent scan the MutationObserver already runs. Existing entries go through upsert's redraw path, scheduleVideoDraw won't double-schedule (it checks videoFrameHandle/animationFrame), drawEntry returns early while contextLost, and destroyed short-circuits after destroy(). Red-green confirmed locally: with the two lines removed, the new test fails with expected 'unavailable' to be 'active', and all 104 tests in the file pass at the head. Out of scope: live (setGrading) clips shown during the loss still aren't recreated, because there's no attribute to rescan. All required CI checks pass.

[heygengenesis]

Verdict: APPROVE — 1 resolved, 0 open, 0 new · 4950fdc3 → 5896694d (only change: the comment line dropped; Comments ratchet green)