team-github.test.ts 'returns gracefully' test calls real gh — network-dependent unit test fails during GitHub outages

[amrmelsayed]

Evidence (2026-08-06/07, during the GitHub Partial System Outage)

src/__tests__/team-github.test.ts > fetchTeamGitHubData > returns gracefully when gh CLI succeeds or fails failed on main's Unit Tests during the Actions outage (run 31120464069, second attempt — the first attempt's jobs were outage-cancelled). Same commit passes locally (33/33) with a healthy gh. Nothing in the triggering merge (PR #1342, gemini-builder retirement) touches this area.

Unlike its vi.mocked siblings, this test (line ~241) deliberately invokes the REAL fetchTeamGitHubData → real gh CLI, asserting only that it returns a result object rather than throwing ('In CI, gh may not be authenticated; in dev, it may work'). That makes it a unit test with a live network dependency: during the outage, gh produced a failure mode (timeout/hang or an error shape) that either escaped the graceful path or blew the test timeout — indistinguishable from a regression in the CI signal, and it paged the CI cron accordingly.

Fix directions (either acceptable)

1. Make it hermetic: drive the graceful-degradation contract through the same mock seam the sibling tests use, covering the specific failure shapes (nonzero exit, ENOENT, timeout/kill, garbage stdout). The 'never throws on real gh' property, if wanted at all, belongs in an integration suite that tolerates network flake, not in Unit Tests.
2. If the real-gh smoke is kept: bound it (short timeout, explicit catch-all assertion) and mark it skip-on-network-failure — but note this still leaves a nondeterministic unit test, so option 1 is preferred.

Also worth checking while in there: whether the outage failure mode revealed an actual gap in fetchTeamGitHubData's graceful handling (if the failure was a THROW rather than a test timeout, the production path has an uncaught error shape — the CI log's failure detail will say which).

BUGFIX-sized.