fix: Bump GAF to fix request body loss on 429 retry and connection leaks

[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?

Bumps go-application-framework to include fixes for CLI-1591:

1. Request body preserved on retry — the retry middleware now always prepares a replayable body, so per-status-code retry overrides (e.g. 429 → 3 attempts) re-send the full body. Previously, body buffering was gated on maxAttempts > 1, but the default is 1 — the 429 override to 3 attempts only kicks in after the first response, by which point the body was consumed and never buffered. This caused POST retries (e.g. snyk test dep graphs) to silently send empty bodies.

2. Intermediate response bodies closed between retries — previously, each retry discarded the prior response without closing its body, leaking one TCP connection per retry. Now matches stdlib's Client.do behavior (drain + close).

3. Orphaned transport body closed on permanent 503 — getErrorList reads and replaces the response body for 503 responses but never closed the original. The transport body is now properly closed when it's been replaced.

Where should the reviewer start?

• cliv2/go.mod — GAF version bump
• GAF PR: fix: Buffer request body for retry overrides, close intermediate response bodies go-application-framework#629

How should this be manually tested?

1. Build the CLI from this branch
2. Run snyk test against a project that triggers rate limiting (429)
3. Verify the CLI retries and succeeds (or exhausts retries cleanly) instead of failing immediately with an empty-body error

Risk assessment (Low | Medium | High)?

Medium — changes are in the retry middleware's core request/response lifecycle, affecting every network request that hits a retryable status code. While each fix is additive (buffering bodies that weren't buffered, closing bodies that weren't closed), the retry path is critical infrastructure and regressions could impact any CLI command that makes API calls.

What are the relevant tickets?

CLI-1591

[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.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 4 relevant code sections from 2 files (average relevance: 0.95) scripts/upgrade-snyk-go-dependencies.go (lines 1-149) package-lock.json (3 segments, lines 19755-19977)

🤖 Repository instructions applied (from AGENTS.md)