test/apps-busy.test.ts runs in under 10 s, every test under 1 s #10874

scripts/test-times.json now lists test/apps-busy.test.ts at 3.9 s, down from 26.4 s. The stored time was the only part of #10865 still undone. The test file itself was already fixed on main in dba5ca319 (#10224). That fix builds the app and both deploys once in beforeAll. It replaced the fixed sleeps with a fake sweep clock (sweepAt) and test-app endpoints that wait until the test tells them to finish. The pull for that fix never updated the stored time, so it still showed the old number. This pull changes only that one line.

Times measured here (bun test test/apps-busy.test.ts, four runs):

• The whole file took 3.73–3.95 s.
• Each test took 0.31–0.41 s (from the JUnit report). All 5 pass and none were removed.
• Setup takes about 2.3 s of that: about 1.45 s to create the app, then about 0.5 s and 0.35 s for the two deploys.

Not done:

• No timing from the check itself. The run-log API returns only the end of the log, which doesn't include this file's shard. The forge's own times cache is outside what this sandbox can read. So 3.9 s is the time on this crew machine, not on the check. The check's log for this push will show the real figure.
• Waits left as they are. The waits that remain check the runtime's state every 5 ms until a condition holds. They are not fixed sleeps. Making the runtime announce these changes as events would add a feature, which is outside this issue.
• No plan posted on the issue. The keep_plan tool was not available in this run.

To check: bun test test/apps-busy.test.ts --reporter=junit --reporter-outfile=$TMPDIR/j.xml and read the per-test time attributes.

🤖 Generated with Claude Code

Closes #10865

scripts/test-times.json now lists test/apps-busy.test.ts at 3.9 s, down from 26.4 s. The stored time was the only part of #10865 still undone. The test file itself was already fixed on main in dba5ca319 (#10224). That fix builds the app and both deploys once in beforeAll. It replaced the fixed sleeps with a fake sweep clock (sweepAt) and test-app endpoints that wait until the test tells them to finish. The pull for that fix never updated the stored time, so it still showed the old number. This pull changes only that one line.

Times measured here (bun test test/apps-busy.test.ts, four runs):

• The whole file took 3.73–3.95 s.
• Each test took 0.31–0.41 s (from the JUnit report). All 5 pass and none were removed.
• Setup takes about 2.3 s of that: about 1.45 s to create the app, then about 0.5 s and 0.35 s for the two deploys.

Not done:

• No timing from the check itself. The run-log API returns only the end of the log, which doesn't include this file's shard. The forge's own times cache is outside what this sandbox can read. So 3.9 s is the time on this crew machine, not on the check. The check's log for this push will show the real figure.
• Waits left as they are. The waits that remain check the runtime's state every 5 ms until a condition holds. They are not fixed sleeps. Making the runtime announce these changes as events would add a feature, which is outside this issue.
• No plan posted on the issue. The keep_plan tool was not available in this run.

To check: bun test test/apps-busy.test.ts --reporter=junit --reporter-outfile=$TMPDIR/j.xml and read the per-test time attributes.

🤖 Generated with Claude Code