build: bump grpc to v1.83.1

[ziggie1984]

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 bump pulls the transitive requirements forward to what grpc v1.83.1
declares (golang.org/x/net, golang.org/x/sys, golang.org/x/text,
golang.org/x/crypto, golang.org/x/mod, golang.org/x/tools,
golang.org/x/term, and the two genproto/googleapis modules).
google.golang.org/protobuf is unchanged at v1.36.11, so the existing
protobuf-go-hex-display replace directive is untouched.

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

A second commit runs go mod tidy in the independently-versioned kvdb module
so its transitive requirements and checksums line up with the version selected
by the module graph, matching what was done for the last bump.

Steps to Test

• go build ./...
• make build
• go test ./rpcperms/...
• make rpc produces no changes to generated code (the protobuf toolchain
  version is pinned separately in lnrpc/Dockerfile and is unaffected)

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: MEDIUM

Classified from 5 changed files | 154 lines changed

🟡 Medium (2 files)

• go.mod - root module dependency/toolchain version bump
• go.sum - checksum updates accompanying go.mod bump

🟡 Medium (2 files, kvdb submodule)

• kvdb/go.mod - kvdb submodule dependency/toolchain version bump
• kvdb/go.sum - checksum updates accompanying kvdb go.mod bump

🟢 Low (1 file)

• .github/workflows/main.yml - CI/CD configuration change

Analysis

This PR only touches Go module/toolchain files (go.mod/go.sum in the root and kvdb submodule) plus a one-line CI workflow tweak — consistent with a Go toolchain/dependency version bump. No source files in any critical or high-severity package are touched, file count (5) and line count (154) are both well under the bump thresholds, and no single critical package is affected. Severity is set to MEDIUM based on the go.mod/go.sum changes.

---

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

[starius]

LGTM!

Small optional nit added.

[starius]

Nit: x/crypto v0.51.0 can now return an error from ChaCha initialization under explicit strict FIPS mode, while brontide/noise.go:174 assumes only key length can fail. Since Lightning transport requires ChaCha and strict FIPS mode is inherently unsuitable, the code is still safe, but the comment is stale. We can expand it, to clarify the invariant:

diff --git a/brontide/noise.go b/brontide/noise.go
index a1b7cd4dd..a3b7c205d 100644
--- a/brontide/noise.go
+++ b/brontide/noise.go
@@ -172,7 +172,10 @@ func (c *cipherState) InitializeKey(key [32]byte) {
        c.nonce = 0

        // Safe to ignore the error here as our key is properly sized
-       // (32-bytes).
+       // (32-bytes). Starting with x/crypto v0.51.0, this can also return an
+       // error when Go's strict FIPS 140-only mode is enabled. Brontide requires
+       // ChaCha20-Poly1305, which isn't permitted in that mode, so lnd cannot
+       // operate with strict FIPS enforcement enabled.
        c.cipher, _ = chacha20poly1305.New(c.secretKey[:])
 }

[ziggie1984]

Good catch, added the comment expansion in c348a58 as a separate commit.

I went with the comment-only route rather than actually catching the error, for two reasons. First, the path is unreachable for lnd: brontide mandates ChaCha20-Poly1305, which strict FIPS 140-only mode forbids, so the two can't coexist. Second, propagating the error would mean adding an error return to InitializeKey -> rotateKey -> Encrypt, but Encrypt returns only []byte and calls rotateKey from a defer, so that's an invasive signature change through hot-path transport code, out of scope for a dependency bump.

[github-actions]

⚠️ Severity changed: MEDIUM → CRITICAL (files changed since last classification)

🔴 PR Severity: CRITICAL

Classified from 6 changed files | 159 lines changed

🔴 Critical (1 file)

• brontide/noise.go - Noise protocol / encrypted peer connection handshake code

🟡 Medium (4 files)

• go.mod - root module dependency/toolchain version bump
• go.sum - checksum updates accompanying go.mod bump
• kvdb/go.mod - kvdb submodule dependency/toolchain version bump
• kvdb/go.sum - checksum updates accompanying kvdb go.mod bump

🟢 Low (1 file)

• .github/workflows/main.yml - CI/CD configuration change

Analysis

This PR was previously classified as MEDIUM (grpc dependency bump only), but it now also modifies brontide/noise.go, which implements the Noise protocol handshake used for encrypted peer connections. Changes to brontide/* require expert review regardless of size, so the severity is raised to CRITICAL. File count (6) and line count (159) are both well under the bump thresholds, so the escalation here comes solely from the package touched, not from PR size.

---

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

[gijswijs]

Commit 1 leaves kvdb/go.mod in an inconsistent intermediate state (grpc v1.82.1) that commit 2 immediately fixes. Squashing would be tidier imho, but each commit still builds, so it's harmless.

[ziggie1984]

Good catch @gijswijs — fixed in a force-push. That intermediate kvdb state was an artifact of re-basing the earlier v1.82.1 revision onto v1.83.1: a git reset --soft had kept the stale v1.82.1 kvdb change staged, so commit 1 picked it up.

The commits are rebuilt so the split is clean now:

• commit 1 (build: bump grpc to v1.83.1) touches only the root go.mod/go.sum and the CI pin — kvdb is untouched;
• commit 2 (kvdb: bump grpc module floor) takes kvdb straight from v1.79.3 to v1.83.1, no intermediate.

The final tree is byte-identical to before, and each commit builds on its own.