test(pep): look for the rescue lane, not for the lowest-numbered one

[bojieli]

TestAutoFlowInstallsTCPRescueAfterAllQUICLanesFail has been failing roughly half of recent CI runs on ubuntu-24.04 amd64 while passing on the other five platforms. It failed #93 before that change merged, and it failed the build gate of the v0.6.0 release workflow, which is what stopped the tag from publishing on its first attempt.

It is the wrong question, not a tight timeout

lanes := sessionFlow.flow.healthyLanes()
if len(lanes) > 0 {
    lane = lanes[0]          // ← only ever inspects the lowest lane id
}
...
if closedQUIC && lane != nil && lane.kind == TransportTCP {

healthyLanes() ends with sort.Slice(lanes, func(i, j int) bool { return lanes[i].id < lanes[j].id }), and the QUIC lane is created first. So the original lane holds position zero until it is evicted from the healthy set — and a TCP rescue could be fully installed while lanes[0] still reported a QUIC lane, leaving the test spinning until its deadline for a state it had already reached.

The test means "is there a TCP lane" and was asking "does a TCP lane happen to sort first". It now scans every healthy lane.

Timing

The deadline moves 5s → 20s as well. Eight consecutive local runs complete in 6.5s total — under a second each — so the rescue is fast and the extra budget costs a passing run nothing. It only stops a loaded runner from being scored as a failed rescue.

Not in v0.6.0

The v0.6.0 tag is immutable and predates this commit, so this ships in the next release. v0.6.0's own artifacts are built from the tagged tree, which a green v0.6.0-rc.2 validated across all six platforms.

🤖 Generated with Claude Code

https://claude.ai/code/session_011HCTFdNai8pNgSyJwV8vGW