An admin re-checks, in one call, every open pull whose latest check failed on one named test #6448

POST /api/v1/repos/:owner/:name/checks/recheck with { "test": "…" } now queues a fresh check for every open pull whose latest check on its current head failed on that test, and answers { queued: [numbers] }. The new tests and the OpenAPI and contract tests pass. bun x tsc --noEmit could not run: bun's type definitions are not found in this sandbox, so the type check is unverified.

• Access: it takes a repository admin on the admin token scope or a session. A cookie session from a foreign Origin gets 403, and a non-admin gets 404. The route is in src/http/checks_recheck.ts and the selection logic in src/checks/recheck.ts.
• Test name: it must be 1 to 300 characters, otherwise 400. A pull matches when the failing-test names recorded on its latest check run include the name exactly.
• Cap: at most 50 pulls are queued per call. When more were red, the answer also carries more: <count> and a message saying so.
• Queueing: each pull goes through the existing askCheck, so the check queue's slots and order apply and none is skipped. That call also ignores a pull that waits for a writer's approval or declares no check, so those are not in queued.
• OpenAPI: the route has a row in src/contract/openapi/routes/. I added the new route file to the source list that test/openapi.test.ts scans for registered routes.
• Left out:

- src/checks/queue.ts is unchanged. That file is the merge queue, and checks are queued by checks.request, which askCheck calls, so no enqueue call needed changing. - I found no priority code for approved pulls (#6396) in this tree, so nothing here sets it. It will apply to these re-checks once it lands in the check request path.

• Tests: test/checks-recheck.test.ts covers two pulls red on the named test queued and a third red on another test not; a non-admin getting 404; a foreign Origin refused; an empty, missing or 301-character name getting 400; and a second call queuing nothing.

To try it as an admin: curl -X POST -H "authorization: Bearer $TOKEN" -d '{"test":"<name from the check log>"}' $FORGE_URL/api/v1/repos/OWNER/NAME/checks/recheck.

Closes #6445

POST /api/v1/repos/:owner/:name/checks/recheck with { "test": "…" } now queues a fresh check for every open pull whose latest check on its current head failed on that test, and answers { queued: [numbers] }. The new tests and the OpenAPI and contract tests pass. bun x tsc --noEmit could not run: bun's type definitions are not found in this sandbox, so the type check is unverified.

• Access: it takes a repository admin on the admin token scope or a session. A cookie session from a foreign Origin gets 403, and a non-admin gets 404. The route is in src/http/checks_recheck.ts and the selection logic in src/checks/recheck.ts.
• Test name: it must be 1 to 300 characters, otherwise 400. A pull matches when the failing-test names recorded on its latest check run include the name exactly.
• Cap: at most 50 pulls are queued per call. When more were red, the answer also carries more: <count> and a message saying so.
• Queueing: each pull goes through the existing askCheck, so the check queue's slots and order apply and none is skipped. That call also ignores a pull that waits for a writer's approval or declares no check, so those are not in queued.
• OpenAPI: the route has a row in src/contract/openapi/routes/. I added the new route file to the source list that test/openapi.test.ts scans for registered routes.
• Left out:

- src/checks/queue.ts is unchanged. That file is the merge queue, and checks are queued by checks.request, which askCheck calls, so no enqueue call needed changing. - I found no priority code for approved pulls (#6396) in this tree, so nothing here sets it. It will apply to these re-checks once it lands in the check request path.

• Tests: test/checks-recheck.test.ts covers two pulls red on the named test queued and a third red on another test not; a non-admin getting 404; a foreign Origin refused; an empty, missing or 301-character name getting 400; and a second call queuing nothing.

To try it as an admin: curl -X POST -H "authorization: Bearer $TOKEN" -d '{"test":"<name from the check log>"}' $FORGE_URL/api/v1/repos/OWNER/NAME/checks/recheck.

Both review points are addressed and pushed to the branch. test/checks-recheck.test.ts passes (6 tests); I did not rerun the OpenAPI and contract tests after this change.

• Cap test: recheckNamed now takes the cap as an optional last argument, defaulting to RECHECK_MAX (50), as suggested. A new test makes two pulls red on one test and calls it with a cap of 1. The first call queues one pull and reports left: 1. The second call queues the other and reports left: 0. It also asserts that RECHECK_MAX is 50.
• README: a paragraph sits beside the drills one. It gives the route, the {test} body (the name exactly as the check log's failing names show it, 1 to 300 characters, otherwise 400), the admin-only rule (404 for others) and the same-origin rule for sessions. It also covers the 50 cap with more and message, and says a pull waiting for a writer's approval or with no declared check is not in queued.

Not covered: the HTTP route's own more and message fields are still untested end to end. The route uses the fixed cap of 50, and I did not open 51 pulls for a test. The cap logic itself is covered at the function level.