Remove blah2's built-in tracker

[Purple10101]

Summary

Removes blah2's built-in tracker outright: Track, Tracker, their tests, the
track socket and port, /api/tracker and its TCP listener, and the config
keys. -1104 lines.

It leaked, and nothing consumed it.

Why remove rather than fix

Track::remove() erased six of its seven parallel per-track vectors and missed
nInactive, which add() pushes for every track created. Tracker::process
then returned std::make_unique<Track>(track) — a deep copy of the whole Track,
every CPI — so that ever-growing vector was allocated, copied and freed twice
a second with more than one instance resident at peak.

Measured on fairforest-b over a 50 minute window at ~78 h uptime: 100% of RSS
growth landed in exactly those two mappings, at 2.00 MB/h. No other mapping
moved. On a 2 GB board with no swap and ~870 MB free, that is 18 days to
exhaustion.

Reproduced offline against pristine origin/main (real Tracker/Track,
synthetic detections, 20,000 CPIs = 2.78 simulated hours):

    iter    simh   RSS kB    dRSS   nInactive    id   assoc
    2500    0.35     4304    1328       37500    30      30
   20000    2.78     8400    5424      300000    30      30

id holds correct steady state at 30. nInactive climbs linearly to 300,000.

Fixing the missing erase alone was viable, but nothing reads this tracker:

• blah2-api's /api/tracker was the only reader of the track socket, and the
  only reference to that endpoint anywhere was a debug link in a collapsed
  section of web/html/controller/index.html.
• retina-gui's Tracker page proxies retina-tracker's SSE feed, not this.
• It never emits a non-tentative track anyway: the association gate is pinned at
  the origin (delayPredict/dopplerPredict are initialised to 0.0 and never
  assigned from the prediction), so with minDelay: 5 nothing can ever
  associate and Track::to_json omits tentative tracks. /api/tracker has
  always returned data: [].

Live verification on owl-ded9

Deployed with the matching retina-node change (see below) and left overnight.

check	result
starts against the stripped config	restarts=0, exit=0, zero errors or aborts
RSPduo	NumDevs=1, normal startup
tracker key in /api/timing	gone
/api/tracker	404
listeners on port 3003	0
map / detection / timing / iqdata / timestamp	all 200
retina-tracker sidecar	restarts=0, still consuming the detection feed
duty	92.9%

Memory over 12.84 h and 86,919 CPIs:

  0.36h  281.98 -> 283.83   +1.84     warm-up ends
  1.36h  283.83 -> 284.44   +0.61     gap 1.00h
  4.36h  284.44 -> 284.98   +0.55     gap 3.00h
 10.78h  285.05 -> 285.81   +0.77     gap 6.25h

After warm-up: +1.98 MB over 11.87 h = 0.167 MB/h, a 12x reduction on
the 2.00 MB/h it replaces. The character changed too: the old leak moved on
every sample, this is a flat line with three isolated steps whose gaps are
doubling (1 h, 3 h, 6.25 h) — the signature of a geometrically-growing
structure rather than linear accumulation. VmHWM == VmRSS at the end, so
nothing transient is hiding above it.

Runway on a 2 GB board goes from 18 days to roughly 7 months.

Deployment: three images move together

blah2, blah2-api and config-merger must be deployed as a set.

The matching retina-node change strips process.tracker and
network.ports.track from the merged config. Against that config:

• an old blah2 reads process.tracker.enable through ryml, whose default
  error handler calls abort() — it dies rather than warns;
• an old blah2-api calls server_tracker.listen(config.network.ports.track)
  with the key gone, so it binds a random free port, silently.

The second one is easy to miss: during verification /api/tracker kept
answering 200 after the config was stripped, purely because the API had not
restarted and was still holding its original bind on 3003.

Recreating blah2-api also takes blah2 down with it (exit 0, Error sending data: Broken pipe, recovers). Pre-existing and unrelated to this change, but it
means the rollout costs a brief blah2 restart.

Not addressed here

The association bug that makes the tracker useless is moot now, but the same
defects exist in the retina-tracker sidecar's lineage if it was ported from
this code — worth a look separately.

🤖 Generated with Claude Code

[Purple10101]

Pairs with offworldlabs/retina-node#40, which makes the config change reach deployed nodes. Deploy blah2, blah2-api and config-merger together.