test/studio.test.ts: a pull's preview case waits for the deploy it reads, and the file rejoins the gate #1044

Pillar: P0 Trust (umbrella #586). The issue this waits on moves test/studio.test.ts out of the gate because since 2026-10-11 the gate on main has been red on cases no pull touched, so nearly every pull's check failed on them. This issue owns bringing it back.

Replaces #896, parked twice:

• the run ended without a pull: no changes pushed (timeout)
• the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #979 closed).

What #896 said:

Under P0 Trust: this test is in the gate and fails on a busy runner because of a timing race. That race closed pull #840 for #656. Same kind of fix as #842, for a test #842 doesn't cover.

test/studio.test.ts:2725 ("a change's page names its preview's data as its own copy…") polls runtime.envStatus(record, "pull-N") for up to 30 s. The test's own timeout is also 30 s, so on a slow runner the deploy wait uses the whole budget, and the test is killed or fails at toBe("running"). Nothing in the pull under test touched previews.

## Done looks like

- [ ] The test waits on the preview's deploy explicitly, either by awaiting the deploy the forge started for the pull or by a wait helper with a clear failure message. It does not race a deadline equal to its own timeout. The test timeout leaves at least 30 s of headroom over the longest wait.

- [ ] The "Previews" test at test/studio.test.ts:2692 gets the same check, and so does any other envStatus polling loop in test/studio.test.ts.

- [ ] Assertions are unchanged: this changes only how the tests wait, not what they check.

- [ ] bun test test/studio.test.ts passes three times in a row, and the full check (forge.json's check) passes. Quote both outputs in the pull.

## Files

test/studio.test.ts; possibly a small shared wait helper beside the existing test helpers, if #842 hasn't already added one (reuse it if it has).

## Risks

Raising only the timeout hides a real hang. Wait on the deploy itself, and keep a failure message that says which state the preview reached.

Suggested: the builder who takes #842, since it's the same pattern.

Done means.

• [ ] Find why the failing case goes red in the full gate run on a loaded machine and fix that cause. Widening a timeout alone is not a fix; waiting on the event the case reads is.
• [ ] Move test/studio.test.ts from EXCLUDED back to GATE in scripts/gate.ts in the same pull; test/check-list.test.ts stays green.
• [ ] Run the file three times in a row with bun test test/studio.test.ts and give the results in the pull.

Files. test/studio.test.ts, scripts/gate.ts, and the source the cause is in.

Dropped by the planner: test/studio.test.ts is already in GATE in scripts/gate.ts at 2bdf6979 and main's gate is green with it; nothing left for this issue to do.

Correction: the planner could not close this (it is assigned, and closing it is outside my scope). It is still open. The file is already in the gate, so a person can close it as dropped.