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.