Installed network-error and decoder-failure checks

Observed 2026-09-23 on the physical board with the production installed controller and player from image /nix/store/d7r354bnsnffxnwnqblaf3raqvd15190-k230-sd-image.img (source 03cbade). These are root-controlled failure injections with the player running as shell UID 1000, not physical-finger trials.

check.py was copied unchanged to /run/video-recovery-check.py and run with /nix/store/v189xydz6qkcd4cbkixcmv91w8hbc560-python3-riscv64-unknown-linux-gnu-3.14.7/bin/python3. The exact procedure and allowlisted observations are retained here.

• Network startup failure passed. A shell-owned mode-0600 runtime playlist named a deliberately unavailable local endpoint. The production controller exited spontaneously with status 2; its process group, state, IPC socket and playlist were gone before the safety Stop ran. This proves this startup failure, not recovery from every mid-stream network outage.
• MVX initialization-failure fallback did not pass. The fixture temporarily removed access to /dev/video0. It observed the production MVX child but no software child with advancing playback inside the 45-second bound. This does not establish the cause; a controller marker, socket existence or decoder argv alone cannot prove successful fallback. Task 4.2 remains open.

The fixture restored the decoder device permissions in finally, called the normal Stop path, and the subsequent console check reported mode 660. Its failed result is retained rather than converted into an acceptance claim. Follow-up must establish why the player did not enter verified software playback, fix the production behavior if needed, and repeat the bounded test.