Harden CGO fuzz job against cache-hit module fetch failures

[Copilot]

The CGO fuzz matrix on main was failing intermittently when go test -tags=integration ./... tried to fetch a module from proxy.golang.org and received 403. The retry-protected dependency download step was skipped on Go cache hits, leaving this path unprotected.

• Failure mode addressed

  • In the fuzz job, dependency hydration used retry logic only when actions/setup-go reported a cache miss.
  • On cache hit, later go test could still trigger network fetches without retry handling.

• Workflow change

  • Updated .github/workflows/cgo.yml to always run the Download dependencies with retry step in fuzz.
  • Kept existing retry/backoff behavior and diagnostics unchanged; only removed the cache-hit gate.

• Behavioral impact

  • fuzz now consistently pre-downloads modules with retry semantics before integration build/fuzz execution, regardless of cache-hit status.

# before
- name: Download dependencies with retry
  if: steps.setup-go.outputs.cache-hit != 'true'
  run: go mod download

# after
- name: Download dependencies with retry
  run: go mod download

• Fixes [CGO][FUZZ] Workflow failure on main - Run #21193 #50956

[github-actions]

Hey @Copilot 👋 — thanks for diving into the fuzz job workflow failure! This PR is aligned with the project's agentic development process:

✅ On track: The PR addresses a specific CI/CD issue (#50956) and is properly marked as WIP while you're forming your plan and making progress.

✅ Clear scope: This is focused on fixing the fuzz job failure on main — a well-defined, single objective.

✅ Good start: The PR body clearly references the original issue and its details.

Keep the PR description updated as you investigate the failure and implement fixes. Once you've identified the root cause and made changes, feel free to move this out of draft status. The team will be watching for your updates!

Generated by ✅ Contribution Check · auto · 50.2 AIC · ⊞ 8.7K · ◷