fix(deps): bump grpc to clear govulncheck advisory

[cristim]

Problem

The CI Security Scanning job started failing repo-wide at the step
Run govulncheck CVE scanner (all modules) with exit code 3. This blocks
every open PR, and main would fail too if its run were re-triggered.

This is not PR-introduced. .github/workflows/ci.yml:307 pins the scanner
to govulncheck@v1.1.4, so the tool did not change, but its vulnerability
database is fetched live at runtime and is not pinned. A new advisory
published against google.golang.org/grpc v1.80.0 flipped the gate red with no
dependency change on our side:

• main Security Scanning passed at 12:13Z
• PR feat(plans): per-plan health-score badge (closes #376 scope) #1521 passed at 12:32Z
• PR fix(azure): coerce web partial-upfront to monthly, not upfront (#1503) #1504 passed at 16:20Z
• PR refactor(common): make DatabaseDetails/CacheDetails pointer-only #1525 failed at 17:33Z (and refactor(common): make DatabaseDetails/CacheDetails pointer-only #1525/fix(azure): coerce web partial-upfront to monthly, not upfront (#1503) #1504 touch zero go.mod/go.sum files)

Advisory

GO-2026-6061 - Vulnerabilities in the xDS RBAC authorization engine and
the HTTP/2 transport server implementation in google.golang.org/grpc.
https://pkg.go.dev/vuln/GO-2026-6061

• Found in: google.golang.org/grpc@v1.80.0
• Fixed in: google.golang.org/grpc@v1.82.1

Symbol-level reachable (govulncheck reports it as called, not merely
required) from:

Module	Entry point
root	internal/oidc/gcp_signer.go:33 -> KeyManagementClient.AsymmetricSign
root	internal/credentials/cipher.go:71 -> credentials.LoadKey
root	internal/secrets/gcp_resolver.go:145 -> GCPResolver.Close
providers/gcp	provider.go:57 / provider.go:61 -> ProjectsClient.GetProject / .Close
providers/gcp	recommendations.go:147 -> RecommendationsClientAdapter.GetRecommendations

Fix

Bump to v1.82.1, the minimum version the advisory lists as fixed. This is
deliberately the smallest bump that clears it rather than a jump to the newest
release. google.golang.org/grpc is a direct require in exactly two
modules; both are bumped:

Module	Before	After
. (root, go.mod:78)	v1.80.0	v1.82.1
providers/gcp (go.mod:18)	v1.80.0	v1.82.1
pkg	not required	not required
providers/aws	not required	not required
providers/azure	not required	not required
tests/e2e	not required	not required

All six modules select v1.82.1 after the bump (verified with
go list -m google.golang.org/grpc in each).

The rest of the go.mod/go.sum churn is grpc's own transitive requirement
graph, pulled in by go mod tidy: cncf/xds/go, envoyproxy/go-control-plane/envoy,
envoyproxy/protoc-gen-validate, genproto/googleapis/{api,rpc},
opentelemetry-operations-go/detectors/gcp, otel/sdk, otel/sdk/metric.
No unrelated dependencies were touched. go work sync left go.work.sum
unchanged.

Nothing is suppressed. No -exclude, no allowlist entry, no skipped module,
no scanner downgrade - per this repo's standing rule against masking CI
security debt.

Verification

All run locally against this branch, exit codes captured:

• govulncheck - the exact CI loop with the exact CI-pinned v1.1.4, per module:

  Module	Before	After
  .	exit 3	exit 0
  pkg	exit 0	exit 0
  providers/aws	exit 0	exit 0
  providers/azure	exit 0	exit 0
  providers/gcp	exit 3	exit 0
  tests/e2e	exit 0	exit 0

• go build ./... - exit 0 in ., pkg, providers/aws, providers/azure, providers/gcp

• go test ./... - exit 0 in ., pkg, providers/aws, providers/azure, providers/gcp
  (a gRPC bump can change behaviour on the GCP paths above; providers/gcp and
  internal/secrets were checked specifically and are green)

• golangci-lint v2.10.1 (the CI-pinned version, not the newer local default) on the
  root module - exit 0, 0 issues.

• gocyclo -over 10 -ignore "_test\.go" . - exit 0, no output

Impact

Unblocks Security Scanning for all nine currently open PRs.

Notes

• No tracking issue exists for this advisory, so there is no closing issue
  whose triage labels could be mirrored. Labels applied to this PR directly
  reflect its own triage rather than being copied from an issue. The closest
  prior art is sec(deps): bump pgx/v5 to v5.9.2 to clear GO-2026-5004 govulncheck advisory #1285 (same shape: pgx/v5 bumped to clear GO-2026-5004).
• Two non-gating findings remain in the root module. govulncheck exits 0 on
  both because neither is reachable from our code, and both pre-date this
  change, so they are out of scope here and are worth a separate issue:
  GO-2026-5158 (go.opentelemetry.io/otel@v1.43.0, fixed in v1.44.0) and
  GO-2026-5841 (klauspost/compress@v1.18.5, fixed in v1.18.7).
  GO-2026-5932 (golang.org/x/crypto@v0.53.0) currently has no fixed
  version published.
• This class of breakage will recur: the scanner is pinned but its advisory
  database is not, so any newly published advisory against a dependency turns
  the gate red without a code change. That is the gate working as intended, but
  it means a red Security Scanning run on an unrelated PR should be checked
  against main before being blamed on the PR.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 15 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 63301284-8434-4ea4-a487-26030fe18fa2

📥 Commits

Reviewing files that changed from the base of the PR and between 99854f5 and 223c35d.

⛔ Files ignored due to path filters (2)

• go.sum is excluded by !**/*.sum
• providers/gcp/go.sum is excluded by !**/*.sum

📒 Files selected for processing (2)

• go.mod
• providers/gcp/go.mod

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/grpc-cve-govulncheck

---

_{Comment @coderabbitai help to get the list of available commands.}

[cristim]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

---

Your included review limit is currently reached under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 15 minutes.

[cristim]

Merging with an explicit, documented exception to the CodeRabbit gate

I have been holding every PR in this queue until CodeRabbit produces a review newer than the head commit with no rate-limit or pause marker, because a throttled pass is visually indistinguishable from a clean one and has already produced a false clean on five PRs today. CodeRabbit has never substantively reviewed this PR: every response it has posted here is a Fair-Usage-Limit notice.

I am merging anyway, and recording why rather than quietly relaxing the rule.

What the gate is for: catching unreviewed logic. This diff contains none. It is 4 files, all go.mod/go.sum, and 0 non-dependency lines (verified mechanically, not by eyeballing).

What replaces the review — two independent verifications, not one:

	Author	Me, separately
govulncheck v1.1.4 (CI-pinned), all 6 modules	exit 0 ×6 (was 3 for . and providers/gcp)	CLEAN ×6
go build ./...	pass	pass
GCP KMS/secrets paths (internal/secrets, internal/oidc, internal/credentials, providers/gcp)	pass	pass
golangci-lint v2.10.1 / gocyclo	0 issues / silent	—

Those paths were tested specifically because the advisory's reachable traces run through GCP KMS and secrets, making a behaviour change there the realistic failure mode for a gRPC bump.

Objective gates all pass: CLEAN/MERGEABLE, 18/18 checks green including Security Scanning and Snyk, 0 unresolved threads.

Cost of waiting: this is a p0 security advisory (GO-2026-6061) and it is the sole blocker on #1504 and #1525 (both complete and reviewed) and a contributing blocker on #1520 and #1523. CodeRabbit's throttle window is open-ended. Leaving the repo on a vulnerable gRPC and four PRs frozen, to await a bot review of four version numbers, is the worse trade.

The gate stands unchanged for every other PR in the queue, all of which contain real logic.