docs(rig): the OOM daemon has been protecting all along — 21 writes, 0 EACCES

The archived note said install-protect.sh was never run and therefore "the
OOM-protection daemon has never protected anything", reasoning that scsynth and
sclang read ok only because they were already at the target so no write was
attempted. That inference was sound and the premise was wrong.

The unit is installed (Sep 6 23:30) and active since Sep 20, the installed copy
carries CAP_DAC_OVERRIDE in both CapabilityBoundingSet and AmbientCapabilities,
and the journal holds 21 protections with 0 permission errors over 7 days — each
on a process that started at the default, which is the write the note said never
happened: sclang[755981] oom:200->-1000, today at 15:04.

Matters now because gig prep calls for restarting parvagues-sc to warm the
banks, and the unit has no OOMScoreAdjust of its own: this daemon is the only
thing between scsynth and DefaultOOMScoreAdjust=200. It re-protects within
seconds, so the restart is safe.

docs/2026-09-06-07-rig-sessions.md

@@ -11,7 +11,23 @@ listed first; the rest is the original text, unedited, in its original order.
 
 ## Still open when this was archived
 
-* **`sudo tools/install-protect.sh` was never run.** The repo carries the fix
+* ~~**`sudo tools/install-protect.sh` was never run.**~~ **RESOLVED — verified
+  2026-09-22.** It was installed (`/etc/systemd/system/parvagues-protect.service`,
+  dated Sep 6 23:30) and has been `active (running)` since Sep 20 17:24. The
+  acceptance criterion below — "a restart re-protecting on its own" — is met, and
+  measured rather than assumed: the installed unit carries
+  `CapabilityBoundingSet`/`AmbientCapabilities` **including `CAP_DAC_OVERRIDE`**,
+  and its journal shows **21 protections and 0 permission errors** over 7 days,
+  each one a real write on a process that started at the default (e.g.
+  `sclang[755981] oom:200->-1000 sched:SCHED_OTHER/0->FIFO/85`, 2026-09-22
+  15:04). That last line is the proof the note below said was missing: a process
+  at 200 moved to -1000, so a write happened. Consequence for the gig: restarting
+  `parvagues-sc` to warm the banks does NOT leave scsynth killable — the daemon
+  re-protects it within seconds. Note `parvagues-sc.service` itself has no
+  `OOMScoreAdjust`, so this daemon is the only thing standing between scsynth and
+  the user manager's `DefaultOOMScoreAdjust=200`.
+
+  Original note, kept for the record: The repo carries the fix
   (`8f2c510`: the unit's `CapabilityBoundingSet` omitted `CAP_DAC_OVERRIDE`, so
   every write to `/proc/<pid>/oom_score_adj` returned EACCES under an error
   message that said "need root, have uid 0"). Until it is installed, the