[ptescher]

Stacked on #127. Steps 2 and 3 of plans/battlefield-latency.md, chosen after the frame-time experiment showed the 3D view cannot make a picture younger than about 80 ms (#95).

What changes

• The picture moves with the camera (step 3). The app asks for a picture with a margin (10 % each side, 8 % above, 35 % below) and draws it as the camera now sees the flat ground, in 64 bands, each the picture moved and scaled (teleoperation_battlefield::warp). The map is drawn with the camera now, so a pan or a zoom shows in the same frame. A turn keeps the picture's heading until its own picture comes.
• A picture is drawn when it comes (step 2). Battlefield::arrivals wakes the window. While the camera moves, the commander app moves it and draws on animation frames instead of the 33 ms timer.
• The view's main camera is parked 10 km up with --hidden, so its shadow cascades hold no trees (−6 ms a frame in the experiment). The grass stays where the camera stood (ParkedFrom).
• Measure: a new figure, the lag of the battlefield as drawn. A fix: a motion with none of its pictures on screen read as 0 ms late.

Tests

• New expectation «The valley moves with the camera» (at most 20 ms): red at 429 ms before the warp, green at 0 ms after it.
• The 7 battlefield camera expectations pass. «The picture keeps up with the camera» stays pending, now on a 5 s pan of its own: the harness skips every plan that shares an event with a pending expectation.
• Unit tests for the warp: at rest within 0.5 px; after 0.15 s of a full-speed pan or a wheel step, within 1 px; the margin covers the battlefield.
• Unit tests for the park, the grass centre, Rig::moving and a picture waking the window.
• cargo clippy --workspace --all-targets is clean.

Not done

• Not yet seen on screen: whether hills visibly slide during pans, and the app's draw rate on animation frames.
• The console (ground station) still draws the picture unmoved.

🤖 Generated with Claude Code