Companion to audio-lens.py: that watches the audio DEVICE, this watches the
audio ENGINE. Together they answer, in one line, the question that cost PLN
three interruptions today — when the sound stops, did Tidal stop asking, or did
the interface stop playing?

scsynth already answers /status on the port it is listening on, and the reply
carries the live synth count and peak DSP load. SuperDirt rendering silence
sits at its idle floor with no synths; SuperDirt fed by Tidal spawns a synth
per event and the load moves. So three states, and the middle one is the point:

  synths > 0 or peak above the floor    -> Tidal is emitting
  answers but flat at the floor         -> engine fine, NOBODY IS ASKING
  no answer                             -> the server is gone

Nothing in this repo could produce that middle verdict before. During today's
stop every existing lens reported healthy — sclang's OSC loop answered, scsynth
answered, all 48 SuperCollider->Ardour links were up, the interface clocked a
steady 48 kHz — and the sound was gone anyway, because Tidal had stopped
emitting while its process stayed alive, threads scheduled, port 6010 held.

Written with the offsets bug already paid for. The first throwaway version of
this query hardcoded byte offsets into /status.reply and reported 1.68 BILLION
ugens and 0.0% CPU, and I read the CPU figure off it and told PLN the engine was
rendering silence. It was not: reading the typetag properly gives 91 synths at
30.7% peak. A number obviously wrong enough to notice sat right next to a number
wrong enough to mislead, and I used the second one. Hence osc_parse walks the
typetag, and the absurd-value story is in the docstring so the next reader
distrusts hand-rolled offsets on sight.

Passive: /status is a query, allocates nothing, never touches the default
server object, never plays a tone.