[deep-report] Harden 3 unauthenticated GitHub API fallbacks with context + timeout

[github-actions]

Description

Three unauthenticated api.github.com fallback functions dispatch via http.DefaultClient, which has no timeout, so a slow GitHub response can hang the calling goroutine indefinitely during workflow compilation. Verified on main:

• resolveRefToSHAViaPublicAPI — pkg/parser/remote_fetch.go:562 uses http.NewRequest (no ctx) + http.DefaultClient.Do (:572).
• fetchPublicGitHubContentsAPI — pkg/parser/remote_fetch.go:1314 uses http.NewRequest (no ctx) + http.DefaultClient.Do (:1331); called context-free by downloadFileViaPublicAPI, listDirAllFilesViaPublicAPI, and a third caller.
• fetchPublicGitHubAPI — pkg/cli/update_workflows.go:359 correctly uses NewRequestWithContext but still dispatches via http.DefaultClient (:367).

The established fix pattern already exists: constants.DefaultHTTPClientTimeout (30s, pkg/constants/constants.go:279) is used by 7 other HTTP clients (e.g. logs_download.go, mcp_logs_guardrail.go). Switch these three to NewRequestWithContext + a client carrying DefaultHTTPClientTimeout, threading a context.Context through the two context-free functions and their callers.

Expected Impact

Eliminates an indefinite compile-time hang on the third-tier public-API fallback path; brings all HTTP dispatch under the repo timeout convention.

Suggested Agent

Copilot SWE Agent (Go change with an established in-repo pattern).

Estimated Effort

Medium (1-4 hours) — ctx threading through 3 callers.

Data Source

DeepReport 2026-06-30; repository-quality report #42486.

Generated by 🔬 Deep Report · 204.7 AIC · ⌖ 16.9 AIC · ⊞ 10.2K · ◷

• expires on Jul 2, 2026, 7:36 AM UTC-08:00