The four patches fixed both WRITERS of Ardour's scheduling policy. Nothing
touched the readers, and that is the half that bites after the fix lands:

  - `parvagues-protect --check` demands SCHED_FIFO of every target, so
    Ardour at prio 0 would read UNPROTECTED forever and check() would exit
    non-zero by design. Its exit code is what the gate, the Bridge and
    gig-up believe, so a green rig would have shown a red Ardour all night
    while burying the one signal worth having: is scsynth really covered?
  - `perf-audio` still printed "Set Ardour (PID …) to real-time priority
    80" and the same for every child, while deliberately doing neither.

check() now reads the target's own prio out of the TARGETS row, so prio 0
means "want the OOM shield, leave scheduling alone" and prints
`sched=SCHED_OTHER (oom shield only, by design)`. prio > 0 is untouched:
scsynth/90, sclang/85 and pipewire/95 are judged exactly as before.

Verified on copies of both root files, not on the originals:

  - all 8 patches apply, both files still bash -n clean
  - second --apply says "already applied" (the predicate had to name Ardour;
    perf-audio says "real-time priority 80" about aseqdump too, which this
    fix leaves alone, so the loose grep could never have been true)
  - verdict truth table 8/8, including the two rows that matter: a shielded
    Ardour on SCHED_OTHER is ok, and an UNSHIELDED one is still a fault
  - the patched check() run against the live processes prints
    `ok ardour[615285] oom_score_adj=-1000 sched=SCHED_OTHER (oom shield
    only, by design)` where the old one would have said UNPROTECTED, and
    still flags scsynth and sclang, which are genuinely uncovered right now

Same shape as this morning's preload bug, one file over: the emitter changed
and the checker did not, so the checker lied. It is worth saying once more
that it did not merely miss a fault — it invented one.