Flaky test: opencode.contract first-key gap measures a /command send from the previous send's requests #2143

server/opencode.contract.test.ts "never waits on the event stream before the first key, in all three delivery paths" fails on loaded CI runners, always on the prompt path:

first-key gaps (ms): {"immediate/slow":213,"queued/slow":260,"prompt/slow":1388,...,"prompt/error":189}
first-key gaps (ms): {"immediate/slow":123,"queued/slow":194,"prompt/slow":1063,...,"prompt/error":715}
expect(Object.entries(gaps).filter(([, gap]) => gap >= 1_000)).toEqual([])

(Integration tests, jobs 122546701342 on #2098 and 122546191641 on #2096; reruns pass.)

Cause

The gap is measured from lastRequestAt, the last request the fake service received, to the stand-in's report of the send's first byte. A /review send (the prompt path) types its first key before it asks the service anything: probed on P620, the first byte is read 4-5 ms after the submit, and this send's own session lookup and /api/event request arrive 100 ms after that. So for prompt, lastRequestAt still holds a request of the previous iteration (the queued send), and the "gap" is however long that iteration's tail took (its idle report, the rest of its typing, its pending-messages frame) on the host at that moment. It says nothing about waiting on the event stream.

The report also travels by a fetch from the stand-in, which adds that process's scheduling to every gap.

Suggested fix

Measure each send from the last thing it waited on itself (its submit, the queued send's idle report, or a request of the bridge's that came after them and before the first byte), and take the first byte's time from the stand-in's own read, not from when its report arrives. The 1 s bound then still fails a bridge that waits up to 1.5 s for the stream.