fix(sandbox): drain discarded GitHub response bodies in runtime detection

[pedrofrxncx]

Follows #7109/#7087/#7104, which fixed the same undrained-body class in the GitHub provider client, GITHUB_LIST_USER_ORGS, and the file-storage tarball fetch. github-runtime-detect.ts's fetchGithubFile had the identical gap.

probeRuntime (called from SANDBOX_START's runtime detection) fires up to 8 parallel GitHub Contents API requests per repo — one per candidate lockfile path (deno.json, bun.lock, pnpm-lock.yaml, package.json, etc.) plus the port-source files. Only one of those paths actually exists in a given repo, so on every other one GitHub answers 404 and fetchGithubFile returned null immediately without draining res.body. Because probeRuntime runs the fetches with Promise.all, this leaves several unread response bodies per sandbox start, holding the underlying connections open longer than necessary under Bun's fetch implementation — the same connection-hygiene issue the sibling PRs fixed.

Fix: drain the body (await res.body?.cancel().catch(() => {})) before returning null on the !res.ok path, matching the pattern already used everywhere else in apps/api/src/git-providers/github/.

Behavior is unchanged — same early return, same fallback to clone-only on any non-2xx response — this only ensures the body is released.

Verify: cd apps/api && bunx tsc --noEmit (clean) and bunx oxlint apps/api/src/shared/github-runtime-detect.ts (0 warnings/errors). No test added — this is a pure resource-drain fix with no behavior change, same as #7109/#7087/#7104 which also shipped without new tests; full CI validates the rest.

---

Summary by cubic

Drains discarded GitHub response bodies during sandbox runtime detection so unread 404 bodies don't hold connections open. fetchGithubFile now cancels the body before returning null on non-OK responses, matching the pattern used elsewhere in the GitHub provider. Behavior is unchanged: failed probes still fall back to clone-only.

^{Written for commit 3e2928b. Summary will update on new commits.}

[pedrofrxncx]

Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR.

[studio-bot:stale-close]