fix: Use GAF network stack for license downloads

[danskmt]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Fixes GitHub 429 rate-limiting failures during third-party license preparation (CLI-1402) by switching manual license downloads from a plain http.Client to the GAF network stack.

• manualLicenseDownload uses an *http.Client from networking.NewNetworkAccess(), which provides automatic retry with backoff on 429/5xx, Retry-After support, and proxy/TLS behaviour aligned with the rest of the CLI.
• The User-Agent header is set via GAF's AddHeaderField instead of per-request construction.
• maxDownloadAttempts is set to 5.
• The client sets an explicit Timeout of 60 seconds so individual downloads cannot hang indefinitely.

Where should the reviewer start?

• cliv2/scripts/prepare_licenses.go — newHTTPClient (GAF + timeout), updated manualLicenseDownload signature
• cliv2/scripts/prepare_licenses_test.go — TestNewHTTPClient_SetsUserAgent, TestNewHTTPClient_RetriesOn429, and existing tests migrated to testify where touched

How should this be manually tested?

1. make clean && make build — licenses download successfully using the GAF client
2. From cliv2/, run go test ./scripts/ (or rely on CI: make openboxtest runs go test -cover ./..., which includes the scripts package)

Any background context you want to provide?

The license step fetches a few files from raw.githubusercontent.com. Parallel CI can trigger 429 responses. The previous client had a fixed timeout but no retries on those responses, so builds could flake. GAF’s middleware adds retries; the 60s client timeout caps how long a single download can block.

What's the product update that needs to be communicated to CLI users?

None. This is an internal build infrastructure fix with no user-facing changes.

Risk assessment (Low | Medium | High)?

Low — only affects build-time license preparation, not CLI runtime behaviour. GAF is already a dependency and its networking stack is used by the CLI itself.

Any background context you want to provide?

The license preparation step downloads a handful of licenses from raw.githubusercontent.com. Under load (e.g. parallel CI jobs), GitHub returns 429 responses. The previous bare http.Client had no retry logic, causing flaky build failures. GAF's networking middleware handles this transparently.

What are the relevant tickets?

CLI-1402

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[PeterSchafer]

@danskmt please cleanup the PR description to the latest state

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 8 relevant code sections from 8 files (average relevance: 1.00) scripts/upgrade-snyk-go-dependencies.go (lines 1-135) cliv2/cmd/cliv2/main.go (lines 1-202) cliv2/cmd/cliv2/instrumentation.go (lines 1-77) cliv2/internal/cliv2/cliv2.go (lines 1-314) cliv2/internal/proxy/proxy.go (lines 1-267) cliv2/cmd/cliv2/debug.go (lines 1-73) scripts/build-ts-binary-wrapper-locally.go (lines 1-261) ... and 1 more file(s)