Implement APR repo creation under the submitting customer's own GitHub account (their OAuth, not a fixed account)

[JSONbored]

Context

Corrected again 2026-07-21 — the previous version of this issue was still wrong. It specced creating the repo with JSONbored's own OAuth token, which would put every APR repo under JSONbored/<repo-name> regardless of who actually submitted the idea. That's not the intended behavior: an APR repo must be created under the submitting customer's own GitHub account (e.g. joesmoe/<repo-name> for a customer logged in as joesmoe), using their OAuth authorization, not the operator's.

Requirements

Add a function that creates a new GitHub repository owned by the submitting customer, using this codebase's existing multi-user OAuth session infrastructure in src/auth/github-oauth.ts — do not build a new auth flow, and do not use any single fixed account's token:

• The OAuth flow the customer completes before idea submission (per the ratified first-run flow: sign-in gates submission) must request repo scope in addition to read:user — add this as a parameter/variant of the existing flow functions, do not duplicate them.
• Use getLiveSessionGitHubToken(env, sessionId) (src/auth/github-oauth.ts:285) with that specific customer's own session ID — never a fixed/operator session — to obtain a live token for the repo-creation call.
• Call GitHub's "Create a repository for the authenticated user" endpoint (POST /user/repos) with that customer-specific token, returning the created repo's full name (which will be <their-login>/<repo-name>), URL, and node ID.

⚠️ Do not create a GitHub App, an org, an installation-token-based driver, or use any single hardcoded account/session for repo creation. The whole point is that each customer's OAuth grant produces a repo under their own account. A PR that creates repos under a fixed operator account does NOT satisfy this issue.

Deliverables

• A function creating a repo via POST /user/repos, parameterized by a session ID, using that session's own live token — returning the created repo's full name/URL/node ID.
• The repo-scope extension to the existing OAuth flow (explicit variant, not a silent global change — the default login flow must keep requesting only read:user).
• Unit tests covering: success with a mock customer session, and at least one realistic GitHub API error (e.g. repo name collision) handled without an unhandled exception. Mock the GitHub API — no live calls in tests.

Test Coverage Requirements

src/auth/github-oauth.ts and any new file under src/** — standard 99%+ Codecov patch target, both branches of the scope-selection logic.

Expected Outcome

A tested, reusable way to create a repo directly under whichever real customer authorized it, using the existing per-session OAuth token system — no fixed account, no org, no installation-token driver.

Links & Resources

• src/auth/github-oauth.ts (the existing multi-user OAuth session flow this extends — read the whole file, the per-session token storage/refresh pattern is already built and must be reused)
• Design spec: APR repo creation under the submitting customer's own GitHub account (twice-corrected) #7590 (the corrected decision this implements)
• Implement APR repo-transfer-to-customer initiation via GitHub's transfer API #7638 (now closed — this model makes a transfer-to-customer step unnecessary)

[linear-code]

JSO-5398

[JSONbored]

Blocking gap found (2026-07-21): this issue assumes a "loopover" GitHub org exists to create APR repos under — it doesn't. Everything (loopover, metagraphed, awesome-claude) currently lives under the JSONbored personal account. A GitHub App cannot create a repo directly under a personal account (confirmed: POST /orgs/{org}/repos requires an org; there is no equivalent for personal accounts via an App's installation token — that specifically requires OAuth repo scope tied to the user, the exact consent step #7590 was designed to avoid).

Prerequisite, maintainer-only, not this issue's job: create an actual GitHub org (e.g. loopover) and install the existing GitHub App on it with administration:write so it can create repos there. That's an account-level action (naming, billing, ownership) only the maintainer can take — not something to scope as a GitHub issue.

This issue's implementation itself doesn't change once that org exists — the org name just needs to be a real, configured value (per this issue's own requirement that it come from config, not be hardcoded) rather than a placeholder. Leaving this issue open and unblocked to start on the code/tests now (which don't require the org to actually exist yet, since the org name is read from config either way) — just flagging that end-to-end testing against a real org can't happen until the org is created.