[MatejKozlovsky]

Problem

A GPU export renders at most EFFECTCRAFT_GPU_INFLIGHT frames at once (1 by default, #879), so frames in flight don't exhaust VRAM. The cap stays on after the GPU has stopped for good: its device was lost, or it ran out of memory and its context was retired. From then on every frame is declined and rendered on the CPU, but still one at a time. A heavy 4K comp that runs out of GPU memory on its first frame then exports more slowly than with GPU acceleration off.

Change

• Accelerator::available() (default true). The GPU accelerator returns false once its context is unhealthy (check_health), which is the same condition that makes it decline every frame.
• The export checks it before each chunk of capped frames. Once the accelerator is unavailable, the rest of the job renders like the CPU path: frames in parallel, with no cap.
• The cap and its windows are unchanged while the GPU is healthy, and so is the uncapped CPU path.
• 3 files, +69/-5. New unit test: frames after the GPU stops render more than one at a time, in order.

Results

RTX 3090 (24 GB), Vulkan, 16 threads. Two 4K bench comps (generated by the bench scripts), 6 frames each, H.264. Both run out of GPU memory on frame 0 on current main.

Comp	CPU only	GPU before	GPU after
Effects stack (4K)	76.5 s	113.1 s	100.7 s
Blur/glow (4K)	47.9 s	75.2 s	61.8 s

• After the change, frames 1-5 render together, where before they rendered one after another.
• The remaining gap to CPU only is frame 0: the GPU spends 5-20 s on it before running out of memory, and the CPU then renders it alone. Starting the CPU sooner, or not trying the GPU on a frame it can't fit, is a separate change.
• Output is identical to the CPU-only render (decoded frame MD5s match), both before and after.
• A healthy GPU export is unaffected, since available() stays true and the cap applies as before.

Tests

• cargo fmt --check, plus cargo clippy --no-deps -D warnings (all targets) on effectcraft-export, effectcraft-render and effectcraft-gpu.
• cargo test -p effectcraft-export: 82 passed, including the new frames_render_in_parallel_once_the_gpu_stops.

Notes

• This is independent of the open GPU PRs. The export scheduler PR (Export: stream frames through a shared CPU/GPU work queue, convert to YUV 4:2:0 on the GPU, and tune to the hardware #898) replaces map_frames. If that lands first, the same check belongs in its GPU worker: stop applying the GPU limit once available() is false.

[bflatastic]

Merged, thank you @MatejKozlovsky! It landed on main with a batch of community PRs, after a full workspace build and test run on Windows: fmt, clippy -D warnings, about 3,500 tests, layers, assets and wasm.