chore(nodes): drop the blah2 bridge and its two hardcoded nodes

[Babissimo]

Retires the in-process poller for Gene's two boxes. radar3-retnode and radar3a-retnode were polled over HTTP once a second each, from a hardcoded list, as the rollback path for v1 ingest. Both are being reflashed to re-enter through the v1 node API, which reaches the pipeline by the same calls the bridge made, so the bridge has no remaining job.

Ticket: 86cb6385b

What goes

services/blah2_bridge.py, backend/config/blah2_nodes.json, the BLAH2_* constants, the main.py wiring, the file's place in the runtime-config overlay, its tests, and the Dockerfile step that copied it into the pristine config image. That last one settles a worry recorded on the ticket: a fresh droplet or a wiped backend-data volume no longer resurrects the poller, because nothing is left to seed it from.

core/task_registry.register_task goes too. The bridge was its only caller, and the dead-code hook fails on it otherwise.

What stays

Both /api/test/radar3/* aliases go with it. They were kept earlier in this branch on the reasoning that their callers were on the droplets, out of a repo grep's reach; that was never checked and is wrong. A read-only sweep of staging and production found no reference outside the route definition, and production's nginx log recorded no request for either across the hour it holds, a window in which /api/test/dashboard took 14 and /api/test/mlat-verification 3. GET /api/test/node/<node_id>/verification and .../detection-range do the same job for any node and are untouched.

services/node_sites.py keeps reading blah2_nodes.json from the runtime overlay. Its comments are corrected here to stop describing the file as the bridge's, but the read stays: while a droplet still holds a seeded copy, that file is what tells the module radar3 and radar3a share a roof, which is what keeps their published positions fuzzed as one site. It skips the file cleanly once it is gone.

Two things to know before merging

This runs ahead of the ticket's own precondition. The Follow-up section gates deletion on "once every node is across", and neither box has registered over v1 yet. That ordering is deliberate, confirmed 2026-09-08, but it means radar3/radar3a go dark at deploy rather than at cutover.

blah2_nodes.json was deleted against a standing constraint. The ticket says not to delete it until 86cb7fdhg is resolved or the calibrated geometry is accepted as lost. The geometry is recoverable from this branch's history and is captured in full on worktree-blah2-discrepancy-record, which is not merged.

After merging

The running app reads backend/data/runtime/blah2_nodes.json, seeded on first boot and authoritative after, so both droplets keep polling until that file is cleared by hand.

Clearing it is safe but not a no-op: services/node_sites.py also reads it, so removing it drops radar3/radar3a's shared-site grouping along with the polling. Both nodes are going away, so that is the intended end state, but do it deliberately rather than as tidying.

Verification

pre-commit run --all-files passes all five hooks; the full backend suite passes, coverage 84.5%. contracts/nodes-v1.openapi.yaml regenerates with no diff.

🤖 Generated with Claude Code

[claude]

Claude finished @Babissimo's task in 7m 13s —— View job

---

Tasks

• Gather context (PR body, changed files, prior review comment)
• Understand the request: run /code-review against this PR (per repo custom instructions)
• Run code review against the current diff (gh pr diff 340, since git diff origin/main...HEAD failed locally due to shallow history)
• Verify candidate findings against the actual diff/tree
• Post results

Result: no new issues since the last review pass

This synchronize only added comment/docstring rewording on top of the prior commit — backend/pipeline/passive_radar.py (+8/-0, new header comment on DEFAULT_NODE_CONFIG), backend/services/node_pipeline.py (+12/-14), backend/services/node_sites.py (comment tweak), and the corresponding renames/trims in test_ingest_event_loop.py / test_node_pipeline.py. All of it is non-functional.

One candidate finding came out of the automated pass and didn't survive verification, so I'm not carrying it forward: it read the new DEFAULT_NODE_CONFIG comment (backend/pipeline/passive_radar.py:54-61) as claiming the fallback geometry is the retired radar3 site, then flagged that the altitude/tx_lon fields don't match the deleted blah2_nodes.json record. Rereading the actual comment, it does the opposite — it deliberately declines to name the site ("Which site, and the fit behind the numbers, is in ClickUp 86cb6385b rather than here: a receiver position is someone's home and this repo is public"), consistent with this being a public repo. DEFAULT_NODE_CONFIG's values are unchanged by this PR; only the explanatory comment above it is new. No discrepancy to fix here.

Everything else matches the previous pass's conclusion: clean deletion, no dangling references to blah2_bridge/register_task/BLAH2_*, node_sites.py correctly keeps reading blah2_nodes.json defensively (path-exists guard) for droplets that still have a seeded copy, and the kept /api/test/radar3/*-adjacent behavior degrades safely. The frame_processor.py:615-621 comment-accuracy nit noted previously (legacy routes/radar.py frames aren't schema-blocked from carrying an adsb key, so the comment's "carry no list at all" is true in practice but not enforced) still applies and is still non-blocking.

No new blockers.