The new-forge repository picker stays fast and usable with 150 repositories #9063

This adds a test that renders /forges/new with 150 repositories. It passes, and I pushed it. The page code needed no change, and I didn't change it. The only file touched is test/new-forge-pick-150.test.ts.

I ran bun test test/new-forge-pick-150.test.ts (3 pass), bun x tsc --noEmit and scripts/gate.ts, and all came back clean. I did not run the full suite, since the forge's check does that on push. I also never called keep_plan, so the issue has no plan.

The test creates 150 repositories for a user, signs in, and covers three behaviours:

• Speed: /forges/new lists all 150 repositories and answers in under 50 ms. The assertion is on the median of 7 requests after one warm-up.
• Picks survive a re-render: posting two picks (alice/app3, alice/app120) re-renders with both ticked and the count reading "2 of 150 repositories picked".
• Search keeps picks: the picker's client script (pickJs) runs under happy-dom (a DOM emulator).

- Typing "app12" narrows the list to 11 shown, and "app3" also narrows to 11. - Returning to "app12" hides app3, but it stays ticked and in the form data, and both picks show as chips. - The count reads "2 of 150 repositories picked; 11 shown". - Clearing the search shows all 150 again.

Closes #8968

This adds a test that renders /forges/new with 150 repositories. It passes, and I pushed it. The page code needed no change, and I didn't change it. The only file touched is test/new-forge-pick-150.test.ts.

I ran bun test test/new-forge-pick-150.test.ts (3 pass), bun x tsc --noEmit and scripts/gate.ts, and all came back clean. I did not run the full suite, since the forge's check does that on push. I also never called keep_plan, so the issue has no plan.

The test creates 150 repositories for a user, signs in, and covers three behaviours:

• Speed: /forges/new lists all 150 repositories and answers in under 50 ms. The assertion is on the median of 7 requests after one warm-up.
• Picks survive a re-render: posting two picks (alice/app3, alice/app120) re-renders with both ticked and the count reading "2 of 150 repositories picked".
• Search keeps picks: the picker's client script (pickJs) runs under happy-dom (a DOM emulator).

- Typing "app12" narrows the list to 11 shown, and "app3" also narrows to 11. - Returning to "app12" hides app3, but it stays ticked and in the form data, and both picks show as chips. - The count reads "2 of 150 repositories picked; 11 shown". - Clearing the search shows all 150 again.

I fixed the failing check by replacing the stopwatch assertion with a count of SQL statements, and pushed it. The new test and the two wall-clock lint tests pass locally (44 pass, 0 fail), and tsc is clean. I didn't rerun the full suite.

The check failed because the repo bans wall-clock bounds in tests (#4429, #7824). That lint flagged the toBeLessThan(50) timing assertion, the test name, and the "50 ms" in the file's header comment. All three were in test/new-forge-pick-150.test.ts.

• What the test asserts now: GET /forges/new with 150 repositories lists all 150 and runs at most 20 SQL statements. It runs 16 today, so a per-repository query would push it past the limit. The count comes from expectWork and requestStatements in test/helpers/work.ts.
• Timing is no longer checked: the issue asked for "under 50 ms", but the repo's rules forbid a clock in tests. The statement count is the stand-in, so nothing now measures milliseconds.
• Unchanged: the other two tests (picks survive a re-render, search keeps picks ticked) are as before, and no page code changed.