One query answers the repositories a person administers, with no counts and no loop per repository #7065

adminRepoIds(db, user) in src/core/admin_repos.ts now answers "which repositories does this person administer" with a single SQL statement. It isn't called from anywhere yet, so /boards still uses the per-repository canAdmin loop. test/admin-repos.test.ts passes (4 tests) and bun x tsc --noEmit is clean. I didn't run the rest of the suite.

• What counts as admin: the user owns the repository, or has an admin-permission team in the owning org (an org's Owners team is one). A forge admin gets every repository. An agent, or no user, gets none. This matches canAdmin.
• Repository grants: the issue lists "by a repository grant" as a route, but I found no per-repository admin grant in the code. The only repository grant is crew membership, which gives agents write access and is not admin. So the "grant" route is covered by the admin team.
• Test: one person is admin by owning a repository, by being in an org's Owners team, and by an admin team in another org. That person also has a repository they can only write to and one they can only read. The result is checked against canAdmin for every repository. A forge admin gets all of them, and an agent and a missing user get none. A wrapper around db.query counts exactly one statement.
• Speed: on 2,000 seeded repositories it returns in under 5 ms.
• Not done: I didn't switch /boards over to the new function, and the issue's file list doesn't include it. I also didn't add a standing check, because canAdmin doesn't check one either.

Closes #7056

adminRepoIds(db, user) in src/core/admin_repos.ts now answers "which repositories does this person administer" with a single SQL statement. It isn't called from anywhere yet, so /boards still uses the per-repository canAdmin loop. test/admin-repos.test.ts passes (4 tests) and bun x tsc --noEmit is clean. I didn't run the rest of the suite.

• What counts as admin: the user owns the repository, or has an admin-permission team in the owning org (an org's Owners team is one). A forge admin gets every repository. An agent, or no user, gets none. This matches canAdmin.
• Repository grants: the issue lists "by a repository grant" as a route, but I found no per-repository admin grant in the code. The only repository grant is crew membership, which gives agents write access and is not admin. So the "grant" route is covered by the admin team.
• Test: one person is admin by owning a repository, by being in an org's Owners team, and by an admin team in another org. That person also has a repository they can only write to and one they can only read. The result is checked against canAdmin for every repository. A forge admin gets all of them, and an agent and a missing user get none. A wrapper around db.query counts exactly one statement.
• Speed: on 2,000 seeded repositories it returns in under 5 ms.
• Not done: I didn't switch /boards over to the new function, and the issue's file list doesn't include it. I also didn't add a standing check, because canAdmin doesn't check one either.

This pull still gives /boards nothing new: adminRepoIds answers in one statement, but /boards isn't wired to it yet. That follow-up is piece 3 of #6846. The review changes are in and pushed. test/admin-repos.test.ts passes (4 tests) after the merge of main. I did not re-run bun x tsc --noEmit after the merge; it was clean before it.

• Speed test: it no longer holds a raw millisecond number. It now uses expectBudget() from test/helpers/budget.ts, with a baseline taken in the same run (a plain scan of the repository table), so load that slows the query slows the baseline too. The ms number is out of the title, and the test now reads "on 2,000 repositories it costs about one scan of the repository table".
• Baseline choice: baselineMs times /healthz on a running server and this test starts none, so the same-run baseline is the table scan instead.
• Agent-owned repositories: the doc comment on adminRepoIds now says it is stricter than canAdmin for an agent's own fork, and never wider. I left a bot-owned repository out of the test. Which answer is right is for the pull that wires /boards to it to decide.
• Rebase: I did not rebase, because force pushes are refused here. I merged origin/main into the branch instead, so the history has a merge commit. If you want it rebased, that needs someone with force-push rights.

The full gate on land was red; the pull is open again. Red tests:

• no tight wall-clock bound in a test > no test file bounds a request or a spawn below the floor
• no raw wall-clock budget in a test (#4429) > no test file holds a speed to a raw ms number

The gate's log: /api/v1/repos/trevato/forge/gates/1793113973278-80d73c789294/log

Red on top of #7073, #7074, which landed first from the same merge-queue candidate: red on its own on that base, or only together with them. Bring this pull up to date with the base and push.

The gate was red on a stale head, so I merged current main into the branch and pushed it (9adfe864).

• Cause: both failing checks flagged test/admin-repos.test.ts:133, expect(performance.now() - t).toBeLessThan(5). That raw wall-clock bound was already replaced by the expectBudget() version in my previous push, and no toBeLessThan is left in the file.
• Check: with main merged, test/flake.test.ts (the two detector suites) and test/admin-repos.test.ts pass together, 32 tests with no failures. bun x tsc --noEmit is clean.
• #7073 and #7074: the merge brought them in, and I saw no interaction with this pull.