[Babissimo]

Why

retina-server marks its aircraft feed dirty once per frame received, in
services/tasks/frame_loop.py, whatever the frame carried. That flag gates the
1 Hz websocket broadcast to the map, so the socket is fed by frames arriving,
not by aircraft existing.

Skipping empty frames made the fleet's silence indistinguishable from a dead
connection. With nothing in any node's beam the broadcast stops, and after 12 s
the map client's watchdog force-closes a healthy websocket and falls back to
HTTP polling, showing POLL in the toolbar. It shows up on an empty world, a
stopped fleet, and a local stack before the fleet comes up.

Real nodes already send empty frames: delay/doppler/snr/adsb_hex carry
only a max_length in the v1 contract, so an all-empty frame is valid and the
hardware sends one per CPI. This removes a behavioural difference between the
synthetic fleet and the hardware it stands in for, which is why POLL meant
something different on testmap than on map.retina.fm.

What

Drops the if frame.get("delay") guard in run_simulation_loop. Two tests
drive one pass of the loop against a stub connection and a world in which
nothing is ever in a beam.

Cost

The send rate is now the configured rate rather than whatever fraction of nodes
happened to see something, so staging runs at the 50 fps its compose file
already describes rather than below it. Empty frames reach the server's archive
buffer like any other; there is no empty-frame fast path in
process_one_frame, though every stage it runs iterates over empty lists.

Verification

pytest: 213 passed. pre-commit run --all-files clean. Both new tests were
confirmed to fail with the guard restored.

Needs a submodule pointer bump in retina-server before staging picks it up.

🤖 Generated with Claude Code