Fix the two flaky CI tests: stale torus readback and random landscape parameters

[genixpro]

Two flaky tests have been failing CI runs on master and PRs whatever their code: CustomGameSetupHarness (from #240) and TorusRenderIntegrationTest. Both are test bugs, not game bugs. This PR changes only the two test files.

How it was reproduced

In a Docker container with CI's Ubuntu 24.04 packages, software GL and xvfb, running CI's exact commands in a loop on master 4ba685c:

Test	Before	After this PR
torus-render-test (scale 1, then scale 3 in the same profile)	8 failures in 45 runs	0 failures in 20 runs
CustomGameSetupHarness (visual)	3 failures in 52 runs	0 failures in 60 runs

The full CI custom-game step also passes with the fix.

TorusRenderIntegrationTest: stale readback

The failing check reads the torus atlas back with glGetTexImage right after drawing it. Mesa's llvmpipe renders on worker threads, and the readback sometimes returned the previous frame:

• The "with worker" capture came back identical to the "without worker" one (503 -> 503; passing runs are 503 -> 639).
• Instrumenting the draw showed the circle was drawn, with the same GL state as in passing runs and no GL error.
• A later recapture of the same scene showed the marker.
• With single-threaded llvmpipe (LP_NUM_THREADS=0), the unchanged test passed 16 of 16.

Fix: glFinish() before the readback.

CustomGameSetupHarness: random parameters leaking into later checks

It failed at three different assertions:

• screen.validMap (line 1174 on master). After "Randomize parameters", the test pressed Regenerate, which keeps the random draw. It meant Reset, as its own comment says ("back to the landscapes' own parameters"). So the final resize ran on a random rain-shadow ridge layout, which could fail the lobby's validation ("The valleys are too narrow for the homes…"). Instrumented, the tile's parameters were non-default at that point in 6 of 6 runs. Fix: press Reset.
• Starts differ between picker and lobby (line 1152). The test applied the picked landscape without the picker's request. The lobby's real Use path (CustomGameScreen.cpp:322) passes it, so without it the lobby kept the random draw it was given earlier. Fix: pass picker.chosenRequest(), and assert the options arrived.
• Corner pixel not black (line 902). The terrain palette has no black, but a colony start near the map corner puts its black number label on that pixel. Fix: check every pixel of the first row and column that no marker covers, so a real letterbox band is still caught.

To rule out a real engine problem behind the start-position mismatch, I also generated 300 requests across every landscape with random parameters three ways: on the main thread, on a new thread, and again after other maps. All matched, so map generation is deterministic.

Limits

• Reproduced on arm64 Docker, not on the x86-64 GitHub runners. CI on this PR is the check there.
• The corner-pixel cause is inferred from the render code (black labels are the only black drawn in the preview). I didn't capture a failing image.
• Players aren't affected by either bug. The game's own screen capture uses glReadPixels on the framebuffer being drawn, not a texture readback, but I didn't test whether it has a similar timing issue under llvmpipe.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MN62g3sFzcFWiMzums3qge