wallpaper: burn the old picture away on Apply

swaybg has no transitions: wallp kills the running one and starts a new
one, which can show a frame of nothing in between. WallpaperSpread puts a
click-through surface on the bottom layer of each screen, above swaybg and
below every window, holding the old picture while wallp runs. A shader
burns it away over the new one: each pixel's threshold mixes its distance
from a random starting point with fractal noise, and a flame and char band
runs just ahead of the front. The surface goes once wallp has exited, or
at once if it failed, since a failed set may have left either picture.

Wallpapers.apply() announces each swap with the old path before wallp
runs, while current still names it. Sets from a terminal get no effect:
by the time wall_h changes, swaybg has already swapped.

The animation is linear, 3.5s: an ease spent its slow ends where nothing
was left to burn, and read as well under the 2.6s it was given. The
compiled .qsb is committed beside its source, since nothing builds it.

AGENTS.md gains the shader cache trap hit on the way: a running shell
keeps a shader by URL, so a recompiled .qsb under the same name is
ignored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 6 insertions, 0 deletions

diff --git a/AGENTS.md b/AGENTS.md
index ca862dd..b7e617e 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -270,6 +270,12 @@ changing that component. The ones that generalise:
   hl.dsp.focus({ window = "address:0x..." })`. This is why
   `~/bin/hypr-windows.sh` is written the way it is, and its syntax was misread
   as legacy oddity worth modernising.
+- **A running shell caches a `ShaderEffect` shader by URL.** Recompiling
+  `burn.frag.qsb` under the same name left the wallpaper transition on the
+  old shader, which logged `ShaderEffect: 'blocks' does not have a matching
+  property` for a uniform the new one had dropped, and drew nothing. A hot
+  reload does not clear it. After changing a shader, rename the `.qsb` or
+  restart the shell.
 - **A focus dispatched while an overlay holds the keyboard is accepted and then
   ignored.** A layer surface with `keyboardFocus: Exclusive` grabs the
   keyboard, and the compositor will not move window focus out from under that