flaky: KVM rig phase probes the control port once and races RigForge's async listener #3170

The KVM rig phase's control-port row failed once in the 2.0.0 re-cut release gate: tier4-kvm rig group 2271@b0403a541773c6f3ead1d3133576e274bb8fc9c3, 2026-10-06 02:54Z.

✗ the control port does not answer even on loopback ('000')

Everything around it passed: the rig mines, the control token is minted and matches the card, the sister feed answers 200 with the token and 401 without, XMRig's API refuses without the token, and the control port is unreachable from an unpinned source.

Not a product change. The re-cut moved the RigForge pin from f5ff047 to b2d4c3d (#3117). The four RigForge commits in between change only tests and the Makefile (git diff --stat f5ff047 b2d4c3d in p2pool-starter-stack/rigforge). The row passed with the identical RigForge runtime in jobs 2102 and 2137 (the control port listens (loopback answers 401)).

Cause (inferred from the code). tests/os/phases/rig.sh checks http://127.0.0.1:8082/ exactly once, right after the XMRig API check. The sister-feed check two lines above retries 12×5 s. RigForge starts its token-gate listeners asynchronously after apply; its own tests had to add the same wait (p2pool-starter-stack/rigforge#574, "wait for token-gate listeners after apply"). So the single attempt races the control listener.

Ask: give the loopback control-port probe the same bounded retry as the sister feed (12×5 s). Keep the failure message, and keep the unpinned-source refusal check strict.

This is test-only and needs a tier4-kvm rig-phase proof. Meanwhile, a rig group that is red only on this row is re-run for the release gate.