[MatejKozlovsky]

Depends on #1523 (fx-owner, 13a49c9).

Root cause

With several frames in flight, VRAM fills up with resources we already let go of. A
gpu.mem=detail trace of 4K d_blurglow at 3 in flight, just before the out-of-memory error:

• The allocator held 45 layer-upload textures (6.7 GB). Only 6 still had a live GpuImage
  handle, all in the upload cache. The other 39 (~5.8 GB) were dropped on our side, but wgpu
  hadn't destroyed them yet: it does that only once the submissions that used them complete.
• About 3 GB more was in wgpu's internal staging buffers for queue writes, and 2.6 GB was pool
  textures owned by frames.
• Uploading into pooled textures instead only moved the problem: 14 GB of pool textures sat in
  "pending", and it hit more OOM errors.

So nothing leaks for good: frames in flight record work faster than the GPU retires it.

Fix

Enc::mem_gate runs after each effect call and each layer. Every 8th call it reads the wgpu
allocator report, and if more than the cap is allocated, the frame submits its encoder and waits
for the queue. wgpu then frees what was dropped, and pending pool textures become free.

• Cap: wgpu has no safe query for adapter memory (the workspace forbids unsafe). The default is
  8 GiB on discrete GPUs and 2 GiB on integrated/other adapters. EFFECTCRAFT_GPU_MEMCAP_MB
  overrides it; 0 turns it off.
• Backends without an allocator report (Metal, GL, WebGPU) are never gated.
• The first wait logs one info line.

Results

AMD Ryzen 7 5800X / NVIDIA GeForce RTX 3090 (24 GB), Vulkan, 4K, 6 frames, wall-clock seconds,
no environment variables. 3 runs each, interleaved base/memcap; min / median:

comp	build	in flight	min	median	OOM	output
d_blurglow	base 13a49c9	2	44.75	45.77	0	DEA9290B5BAC
d_blurglow	base 13a49c9	3	(earlier run) 72.94	–	yes	931521E85733 (CPU output: frames that ran out of memory fell back to the CPU path)
d_blurglow	memcap	2	43.86	45.15	0	DEA9290B5BAC
d_blurglow	memcap	3	40.75	44.25	0	DEA9290B5BAC
d_blurglow	memcap	4	41.88	43.30	0	DEA9290B5BAC
c_effects	base 13a49c9	2	40.39	45.53	0	BC9186ED92A5
c_effects	memcap	2	42.92	45.56	0	BC9186ED92A5
c_effects	memcap	3	41.84	45.21	0	BC9186ED92A5
c_effects	memcap	4	41.27	41.41	0	BC9186ED92A5

Correction: All memcap runs match the base's GPU output (DEA9290B5BAC), so none fell back to the CPU. 931521E85733 is the CPU-path output. Plain main's GPU export only matches it because main runs out of memory and silently re-renders on the CPU (the #879 problem). The base at 3 in flight produced it the same way, not because the output was corrupted. DEA9290B5BAC is the genuine GPU output and is within 1/255 of the CPU output on ~0.01% of pixels (PSNR 93 dB).

• At 2 in flight there's no measurable cost; base itself ranges from 40 to 50 s run to run.
• At 3–4 in flight there are no OOM errors and the output is identical. With a 10000 MiB cap on
  the same card, an earlier session measured 3–4 in flight at 36–38 s median; the 8 GiB default
  trades some of that for headroom on smaller cards.

Tests: cargo test -p effectcraft-gpu (EFFECTCRAFT_REQUIRE_GPU=1) on Apple M4: 212 passed, 1
failed (tests_init::opengl_adapters_get_cpu_compositing_at_once: no GL adapter on macOS; it
also fails on base). Metal has no allocator report, so the gate is a no-op there. New unit test
memcap::tests::defaults_and_cadence.