The headroom warning said "pulsar at N% — #7 (highlighter marker pool). This is
the JITTER SOURCE; a Window:Reload is the stopgap". I read that, believed it, and
spent a chunk of a pre-gig evening hunting a leak that is already fixed.

What is actually true as of 2026-08-21:

* Both documented marker leaks are FIXED on the running branch —
  `decorateCodeBlocks` tracks its markers in `blockMarkers` and destroys them
  (6e9f374, 2026-07-18), and `#createPositionMarkers` destroys the previous row
  markers before clearing the map (also 6e9f374; the cached-highlight pool was
  bounded in ba77c4f, 2026-08-03).
* PLN's renderer was **3 minutes old and flat at 112%** across five 2 s samples.
  A leak GROWS. Accumulation cannot explain a fresh process holding steady, so
  whatever the burn is, it is not the marker pool.
* `editor-background` is confirmed in disabledPackages, so it is not that either.
  The sound-browser's three `requestAnimationFrame(processChunk)` loops all
  terminate on `currentIndex < total`, so they are bounded too.

Also worth recording: `ps -o %cpu` is a LIFETIME AVERAGE, not an instantaneous
reading. My first two measurements ("122%", "130%") summed lifetime averages
across the process tree and were meaningless; the honest number comes from
sampling /proc/<pid>/stat utime+stime twice. The main pulsar process reads 2.1%
while a child renderer burns 112% — a tree sum hides which process to look at.

So the warning now reports the symptom, says explicitly that the known leaks are
fixed and that a fresh hot renderer rules out accumulation, and points at
`tidalcycles:highlight-stats` — the package's own live instrument (DOM writes/s,
live markers, RAF rate, active events), which is the only thing that can attribute
a burn INSIDE the renderer. A warning that names the wrong cause is worse than one
that names none: it spends the reader's time defending its guess.