chore(lint): providers/aws module lint debt invisible to root-module CI gate [go part, residual from #1342]

[cristim]

Split from LeanerCloud/cloud-commitments-cli#1342 (cross-component issue, monorepo split; residual scope only, not a straight split)

Background

LeanerCloud/cloud-commitments-cli#1342 tracked burning down 2,769 repo-wide golangci-lint findings that kept the "Lint Code" CI gate red. That work is done: PR LeanerCloud/cloud-commitments-cli#1364 cleared them and #1342 is closed as resolved. This issue is not a like-for-like split of that problem (the repo-wide "Lint Code red" state doesn't currently exist here or anywhere else); it covers a narrower, still-live gap called out in a follow-up comment on #1342.

Scope addition discovered during #27 phase-2 work: the providers/aws module carries its own golangci debt - 134 issues in providers/aws/recommendations alone (misspell 57, godot 28, gocritic 24, govet ~17, staticcheck 1, plus a few others). Two specific items worth calling out for the batch fix: (1) the lenient parseFloat in recommendations/utilization.go silently returns 0 with a warning on unparseable CE numbers - a no-silent-fallback violation on a money path; the new strict parseSPFloat in sp_coverage.go is the pattern to migrate call sites to. (2) recommendations now has four near-identical rate-limited retry wrappers (fetchCoveragePage, fetchUtilizationPage, fetchSPCoveragePage, fetchSPUtilizationPage) - extract a generic fetchWithRetry helper as part of the cleanup. Note CI currently lints only the root module, so this debt is invisible to the gate; the burn-down should either extend CI to all modules or note why not.

Why this repo, and why it's real right now

providers/aws (now living in this repo) has its own go.mod, a separate module from the repo root. golangci-lint-action in ci.yml's "Lint Code" job runs against the repo root only; it does not descend into providers/aws, providers/azure, providers/gcp or pkg as separate modules. Verified live on 2026-09-27: providers/aws/go.mod still exists as a distinct module and ci.yml's lint job still targets only the root. So this module's lint debt (and any other separate-module debt) is genuinely invisible to the gate that #1364 made green, independent of whether the repo-root count is 0.

The 134-finding count above is from the comment on #1342 and has not been re-measured for this repo's current state; a local run attempted during triage hit a Go toolchain version mismatch (gosec/golangci-lint built against a newer Go than the locally installed toolchain), so treat 134 as a starting estimate, not current ground truth.

Acceptance criteria

• Re-measure the current providers/aws golangci-lint finding count in this repo with the CI-pinned golangci-lint version (v2.10.1 per ci.yml), not an ad-hoc local version, and record the real per-linter breakdown before starting the burn-down (don't repeat the old aggregate "134" as if it's still accurate).
• Either extend the "Lint Code" CI job to cover providers/aws (and ideally the other separate-module directories) as part of this work, or land the burn-down and open a distinct follow-up for CI coverage with a documented reason it's separate.
• Fix the two named items called out above as part of the same pass:
  • recommendations/utilization.go's lenient parseFloat silently returns 0 with a warning on unparseable Cost Explorer numbers on a money path; migrate call sites to the strict parseSPFloat pattern already established in sp_coverage.go.
  • Extract a generic fetchWithRetry helper to replace the four near-identical rate-limited retry wrappers (fetchCoveragePage, fetchUtilizationPage, fetchSPCoveragePage, fetchSPUtilizationPage).
• No only-new-issues, no blanket nolint, per the repo's no-masking-CI-debt convention; fix findings for real, in per-linter batches where that's practical.