t27b-lab: take up to two lane requests per master run #8586

Part of epic #8326 (why the loop idles, how to speed up).

The lab runs every new master commit first (15-22 min) and then ONE lane request. Master takes a merge every few minutes, so a queue of 4 requests waits up to 4 master runs: about 1.5-2 h per receipt. On 2026-10-09 to 2026-10-10 a lane agent waited over an hour for one receipt, and #8027's post-merge receipt took more than 2 h.

Change: after each master run, take up to two admitted requests instead of one. One line in contrib/railway/t27b-lab/lab.py, net 0 hand-written lines (#8236). Master runs still come first; their latest.json lags by at most one extra request run.

User Scenarios

• Given a queue of admitted lane requests waiting for lab runs, When a master run completes, Then the lab picks up to two admitted requests (instead of one) before the next master run.
• Given the lab has just finished a master run, When there is only one admitted request in the queue, Then the lab runs that single request before the next master run.
• Given the lab has just finished a master run, When there are zero admitted requests in the queue, Then the lab proceeds directly to the next master run.

Requirements

• FR-001: The lab MUST process up to two admitted lane requests after each master run completes.
• FR-002: The lab MUST still prioritize master runs; a master run MUST execute before any lane requests when a new master commit arrives.
• FR-003: The latest.json artifact MUST lag behind the most recent request run by at most one additional request compared to the previous behavior.

Success Criteria

• grep -n "max_requests_per_master" contrib/railway/t27b-lab/lab.py returns a line showing the value 2 (exit 0)
• A simulated lab run with 4 queued requests completes all 4 requests in 2 master cycles instead of 4 (exit 0)
• The change is a single-line modification in contrib/railway/t27b-lab/lab.py (exit 0)

Boundary

• contrib/railway/t27b-lab/lab.py