github

The staleness sweep's own fallback reviewer (workers/ tasks_staleness.py's _resolve_reviewer_login) -- API-only, no settings UI yet, same scope call Task 6's identity-mapping endpoints made for their own admin surface. Applies to this org's primary connection (get_primary_connection's own "first enabled row" pick, same single- connection assumption every other GitHub call site already makes).

Starts the GitHub App install flow — mints a signed state token binding this install to org.org_id (see app_auth.verify_install_state for why the callback trusts this instead of whatever org happens to be active in the browser that completes it) and points at the App's own install URL, fetched live rather than a hardcoded slug.

Called server-to-server by apps/web's /api/github/callback route (the URL actually registered in the App's settings — GitHub redirects the browser there, not here) once GitHub redirects back with a real installation_id. Every genuine install this app itself started carries state (see install-url above) plus a one-time user-authorization code. The state and live admin session must identify the same GNT org; exchanging the code and checking the installation-scoped user endpoint proves the GitHub user returning from the install can access this installation. setup_action values other than "install" (a pending "request" awaiting an org owner's approval, or a repo-selection "update" from GitHub's own installation settings page, which doesn't carry state at all) aren't handled here — out of scope for this connect flow; re-running gnt connect github covers the update case in practice.