[v0.21.x-branch] Backport #11105: build: bump grpc to v1.83.1

[ziggie1984]

Backport of #11105

Opened manually rather than via the backport bot, since the change touches
.github/ files.

Two deviations from a verbatim replay, both forced by the branch topology:

• go.mod/go.sum were regenerated rather than replayed. master and
  v0.21.x-branch have different module graphs, so the dependency commit
  conflicted. Importing master's files wholesale would have dragged in bumps
  belonging to other master PRs, so the bump was reproduced on the branch with
  go get google.golang.org/grpc@v1.83.1 && go mod tidy. The resulting net diff
  matches the shape of the original: grpc plus the transitive requirements it
  selects (golang.org/x/{crypto,mod,net,sync,sys,term,text,tools}, the two
  genproto/googleapis modules, go.opentelemetry.io/otel*, and
  google.golang.org/protobuf).

• The kvdb: bump grpc module floor commit is omitted as a no-op. master
  carries replace github.com/lightningnetwork/lnd/kvdb => ./kvdb, so the root
  bump flows into the local module there. v0.21.x-branch has no local
  sub-module replaces and consumes published kvdb v1.4.16, so its kvdb
  module graph is independent of the root bump — go mod tidy in kvdb/
  produces no change on this branch.

• A third commit regenerates the RPC stubs. lnrpc/gen_protos_docker.sh
  derives PROTOBUF_VERSION from the protobuf version selected in go.mod,
  and grpc v1.83.1 requires google.golang.org/protobuf v1.36.11, so the
  generator moves from v1.36.10 to v1.36.11 and rewrites the version comment in
  all 17 generated stubs. Without the regen, make rpc-check fails. master
  did not need this because it was already on protobuf v1.36.11 (see 3f3718c,
  which bumped protobuf and regenerated the same 17 files). The diff is the
  version comment only — no generated code changes.

Note the protobuf-go-hex-display replace stays at v1.33.0-hex-display on
this branch (master is at v1.36.11-hex-display). grpc v1.83.1 compiles
against it, so the replace is left untouched.

Steps to Test

• go build ./...
• go vet ./brontide/...
• go test ./brontide/...
• go mod tidy produces no drift in go.mod/go.sum

---

Change Description

Routine maintenance bump of google.golang.org/grpc to the latest release,
v1.83.1, keeping our gRPC dependency current with upstream. The latest
release rolls up a number of upstream fixes and robustness improvements over
the version we currently pin.

The pinned-dependency CI matrix entry in .github/workflows/main.yml is updated
to match, mirroring the previous grpc bump (#10841).

A follow-up commit widens the brontide.InitializeKey comment: x/crypto v0.51.0 adds a FIPS-140-only failure mode to chacha20poly1305.New, which the
bump pulls in.

Pull Request Checklist

Testing

• Your PR passes all CI checks.

Code Style and Documentation

• The change obeys the code style guidelines.
• Commits follow the ideal Git commit structure.
• This is a dependency bump; no-changelog label applied.

[github-actions]

🔴 PR Severity: CRITICAL

gh pr view | 21 files | 158 lines changed

🔴 Critical (1 file)

• brontide/noise.go - encrypted peer connection / Noise protocol code (comment widened to note a FIPS-140-only failure mode introduced by the x/crypto bump)

🟠 High (17 files)

• lnrpc/*.pb.go (17 files) - auto-generated RPC stubs; version-comment-only regen following the google.golang.org/protobuf bump to v1.36.11

🟡 Medium (2 files)

• go.mod - dependency bump: google.golang.org/grpc to v1.83.1 plus transitive requirements
• go.sum - checksum updates for the above

🟢 Low (1 file)

• .github/workflows/main.yml - CI pinned-dependency matrix entry updated to match the grpc bump

Analysis

This is a routine grpc dependency bump (backport of #‌11105) that touches brontide/noise.go, which falls under the brontide/* critical path per classification rules. The actual code change there is a comment widening (documenting a new FIPS-140-only failure mode in chacha20poly1305.New pulled in by the x/crypto bump), not a logic change — but severity is determined by file path, not diff content, so the PR is classified CRITICAL and warrants a look from someone familiar with the Noise protocol implementation to confirm no behavioral change. The 17 .pb.go files are auto-generated version-comment-only regens with no functional diff.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[ziggie1984]

Verifying the regenerated stubs

The stub regeneration in 64e3bb3f6 is a one-line-per-file change (the
protoc-gen-go version comment), but it's worth confirming the branch landed on
the same protobuf toolchain master uses rather than just looking like it did.

Wherever a .proto file is byte-identical between this branch and master, the
generated .pb.go must come out byte-identical too if both ran the same
generator. Checking all such files here:

15 protos identical to master → 15 / 15 generated files byte-identical.

No differences. Same check on the v0.20.x companion (#11110), where the
regeneration is far larger, gives 13 / 13.

make rpc is also idempotent against the committed stubs, so make rpc-check
is clean.