docs: record ffmpeg decode-contract verification recipe + WSL CLR boundary

MyMistakes.md

@@ -67,3 +67,25 @@ block back onto the source that the `awk`s still read. Instead:
 `git status` can't save you here if you don't notice until the file is gone —
 `git checkout -- <path>` from the last commit is the recovery. Cheap insurance:
 restore-then-retry, do it atomically from temp files the first time.
+
+---
+
+## Verifying an ffmpeg decode contract from WSL (no real CLR needed)
+
+(2026-08-31, TASK 21) When a change depends on ffmpeg producing output with an
+exact frame-size contract (rawvideo W×H×4 BGRA), you can prove the **command +
+frame accounting** here without any .NET process:
+
+1. Fetch a **static Linux ffmpeg** into `/tmp/opencode` (no sudo needed):
+   `curl -sLO https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz
+   && tar -xf …`
+2. Generate a tiny known clip: `ffmpeg -f lavfi -i "testsrc2=duration=1:size=640x360:rate=30" -pix_fmt yuv420p clip.mp4`
+3. Decode with **exactly the app's args**: `-f rawvideo -pix_fmt bgra -vf scale=640:360 -an`
+4. Assert `total_bytes % (W*H*4) == 0` (python3) → exact integer frames, no pad.
+
+**Why not a dotnet-spawned ffmpeg here:** the only CLR on this box
+(`/home/gramps/bin/dotnet`) is a **Windows-bound shim** — `Process.Start` resolves
+paths to `\\wsl.localhost\Debian\…` and throws "not a valid application for this
+OS" when handed a Linux ELF ffmpeg. So never plan to have dotnet exec a Linux
+ffmpeg here; verify the contract with shell/python instead, and leave the
+CLR→real-ffmpeg run to the native Windows suite.