feat(slop): the clip renderer exists — first reel rendered from a ParVagues take (#28)

PLN has said repeatedly he is bad at socials and hoped slop would carry that weight.
The plan for this has been complete since the clip planner landed; the renderer had
never been written, so nothing could actually be produced. It can now.

`visuals/slop/render_slop_clip.mjs` takes either a planned cut (`--idea desire --cut 90`,
from clip_ideas.json with its measured tilt/kick-density/novelty and playset choice) or
an arbitrary window of any file (`--audio ... --start ... --dur ...`), and renders a
vertical 1080x1920 reel with Slopmotion reacting to that audio.

DESIGN NOTES WORTH KEEPING

- It lives in THIS repo, not hexa. hexa is Kevin's project and its main is clean; the
  script borrows its node_modules through createRequire instead of being committed
  into someone else's tree. Its scratch files go in hexa/public/__slop and are removed
  in a finally block — nothing is left behind in his working copy.
- Capture is REALTIME via CDP screencast, not per-frame screenshots. Hydra's animation
  clock is wall time, so frame-stepping plays motion back ~3x fast and drifts away
  from the audio it is supposed to be reacting to. Screencast frames arrive timestamped
  and become a vfr->cfr concat, so a dropped frame is a slightly longer one — invisible
  — rather than a wrong clock.
- The bands are computed from the REAL audio through an AnalyserNode, not from the
  synthetic pump the FX-preview script uses. Kick is a fast rise in the sub band above
  its own slow running average, because an absolute threshold would need retuning per
  track while a relative one rides the mix.
- Backdrop clip choice is a hash of the job name, not Math.random: two renders of the
  same cut must be comparable, which is the entire point of a review pipeline.
- The viewport is 9:16 natively rather than a 16:9 scene centre-cropped afterwards,
  which would throw away most of the motion.

TWO ENVIRONMENT PROBLEMS FOUND AND FIXED WITHOUT COLLATERAL

- The hexa checkout could not boot at all: 9 declared dependencies were missing from
  node_modules, so vite 500'd on @supabase/ssr and @vercel/speed-insights. `npm ci`
  refused (lock out of sync with package.json), and plain `npm install` would have
  rewritten package-lock.json — a TRACKED file in Kevin's repo. Installed the 9 with
  --no-save --no-package-lock instead; his tracked files are byte-identical after.
- Playwright 1.60 wants chromium build 1223 and the cache has 1217. Rather than pulling
  ~150 MB into PLN's shared browser cache unasked, the script finds the newest full
  chromium already present. Full chromium, not chrome-headless-shell, which ships
  without the GPU/ANGLE stack this needs.

WHAT IS NOT DONE: frame rate. 7.0 fps at 1080x1920 under swiftshader — the page itself
renders at 7 fps, so it is the GL backend and the machine, not the capture. The two
follow-up measurements (hardware EGL, and half resolution) both came back at 1.1 fps,
which is not a verdict on either: load average was 12.5 with Pulsar burning a core from
the #7 marker leak. They measure the machine. Recorded in FEEDBACK.md with an explicit
warning to re-measure on a quiet box before concluding anything — a false workaround
adopted from a contended benchmark is very hard to remove later.

Deliberately not pushed further tonight: a sustained software-GL render is a CPU load
test, and those do not run at night here while the rig is up.

visuals/slop/FEEDBACK.md

@@ -14,3 +14,28 @@ Format per entry:
 ---
 
 <!-- entries below -->
+
+## 2026-07-29 — the renderer exists and runs end to end
+
+First actual render: 8 s of take 94 (the 2026-07-29 OPAL practice), liquid-metal
+playset, glitch/rgbDelay/liquix/slowmo. Output is a structurally correct vertical
+reel — 1080x1920 H.264 + AAC, audio in sync with the visuals that react to it.
+
+**The open quality gate is FRAME RATE, and it is environmental, not a design flaw.**
+Measured on this machine while the rig was up:
+
+    swiftshader, 1080x1920   7.0 fps   (page rendered 60 frames in 8.4 s)
+    --use-gl=egl (hw), same  1.1 fps   under load 12.5
+    swiftshader, 540x960     1.1 fps   under load 12.5
+
+The second and third numbers are not a verdict on hardware GL or on resolution — they
+were taken with load average at 12.5 (Pulsar burning a core from the #7 marker leak,
+Ardour at 22%, scsynth live). They measure the machine, not the backend. **Re-measure
+on a quiet machine before concluding anything about GL.** Getting this wrong in the
+other direction is how a tool acquires a permanent false workaround.
+
+30 fps is the target; ffmpeg currently duplicates frames up to CFR, so motion is
+choppy while audio and structure are correct.
+
+Not attempted tonight, deliberately: a sustained software-GL render is a CPU load
+test, and those do not run at night on this machine while the rig is up.