NVR Recording Retention Disk Full

Recording pipelines fail badly when retention only catches up after writes have already failed. The safer pattern is prune-before-write, a hard free-byte reserve, and backpressure before camera reconnects and segment writers start crash-looping.

Runbook: Prune Before The Next Recording Write

1. Keep one recent known-good segment per required camera/source before deleting bulk history.
2. Measure by camera/source directory, not only total disk usage.
3. Set a hard reserve: for example, next segment budget plus 10-20 minutes of expected recording growth.
4. Run retention before creating the next segment, not only after a successful write.
5. When reserve cannot be restored, pause new writers and reconnect loops with a visible degraded status.
6. Return an operator message with free bytes, largest source bucket, oldest retained segment, and next cleanup action.

I would turn this into a prune-before-write acceptance test:

- storage writability is checked continuously, not only at startup
- retention uses an absolute free-byte reserve, not only a percent threshold
- before opening a new recording segment, old segments are pruned until next-segment + reserve is available
- if reserve cannot be restored, writers enter a degraded/paused state instead of crash-looping
- the operator message names the largest camera/source bucket and oldest retained segment