parvagues-sc.service is Type=simple, so systemd calls it active the instant
sclang execs -- but scsynth is sclang's child and appears ~8s later. The loop
acted at MISSES_TO_ACT*POLL_SECS = 6s, so every healthy start earned a restart:

  23:17:12 scsynth GONE (3 polls) while parvagues-sc.service is active
           -- restarting (0 prior in window)
  23:17:21 scsynth up after 8s

'0 prior in window' on a start where nothing was wrong. The restart was not the
damage; the rate limit was. Each clean start spent two of systemd's
StartLimitBurst=3, so a second start inside StartLimitIntervalUSec=5min hit the
limit and left the unit failed/start-limit-hit -- refusing to start at all until
reset-failed. On stage that is indistinguishable from a dead rig.

BOOT_GRACE_SECS=30, measured from the unit's own ActiveEnterTimestamp, and it
says 'holding off' in the journal rather than waiting silently. Misses keep
counting through the grace so an expiring grace acts at once. The per-poll
is-active became one show returning both fields: 7.0ms -> 9.4ms, +0.12% of a
core, measured not assumed.

Also cures the watchdog of the same pgrep -x that cost protect a tenth of a
core -- 52.9ms per poll while SC is up (3.0% of a core WHILE PLAYING) against
20.8ms for one stateless /proc/*/comm pass, zero forks. Duplicated from
parvagues-protect rather than shared: that script is copied to /usr/local/bin
and runs as root, so it must not source anything from a user-writable repo.

rig-doctor's check_protect now asks whether protection WORKS: the running
daemon's live CapEff from /proc must include cap_dac_override, and the daemon's
own --check must pass. It was green all through the day the guard could not
write a single oom_score_adj, because it tested that two files existed.

Verified end to end on the rig: protect caught pids created 9min after it
started (oom:200->-1000 on sclang[257669]), and the watchdog held off at 6s and
spent none of the rate limit. Suite 11/11 incl. a new slow-boot regression case;
rig-doctor 46 checks, 0 fail.