deps: bump golang.org/x/text to v0.41.0

[rharding6373]

Bumps the indirect dependency golang.org/x/text from v0.32.0 to v0.41.0 to satisfy the requirement of >= v0.39.0.

v0.41.0 is the highest release that still requires only go 1.25, matching this module's current go directive. v0.42.0 was intentionally avoided because it raises its minimum to go 1.26.0, which would force the same bump on this module and on every downstream consumer of cockroachdb/errors.

x/text is a transitive dependency only (pulled in via golang.org/x/net and grpc); no package in this module imports it directly, so there are no API changes to accommodate. go build, go vet, and the full test suite pass.

---

This change is 

[cockroachlabs-cla-agent]

All committers have signed the CLA.

[ZhouXing19]

From Claude for sanity check:

Verdict: safe to approve. The bump exists to pick up a security fix, and nothing in it adds risk to CockroachDB. The cockroach repo already pins x/text v0.41.0 on master and release-26.4, so merging this PR changes nothing in the cockroach binary. Go always resolves to the highest version any module asks for, and that is already v0.41.0. Sources: go.mod:21 in this repo and the Bazel pin at DEPS.bzl:11907.

What in the bump touches CockroachDB

Why the bump exists. Go advisory GO-2026-5970, also CVE-2026-56852, fixed in v0.39.0. In plain terms: the unicode/norm package has an iterator that walks a string one character at a time. When it meets a broken 4-byte character followed by an accent mark, it stops moving forward but never reports "done", so a caller looping until done spins forever. It is a hang bug, not data corruption or code execution.

I fed the upstream reproducer input to every entry point cockroach could reach, under four versions:

Entry point	v0.32.0	v0.38.0	v0.39.0	v0.41.0
norm.Iter with NFC or NFKC	hangs	hangs	ok	ok
NFC.String, NFD.String, NFC.Bytes, IsNormalString	ok	ok	ok	ok
collate KeyFromString, CompareString	ok	ok	ok	ok
cases.Upper, cases.Lower	ok	ok	ok	ok

Only the iterator hangs. CockroachDB calls norm in two places, identifier normalization in pkg/sql/lexbase/normalize.go and collated LIKE in pkg/sql/sem/eval/match.go, and both use String, not the iterator. No file under pkg/ references norm.Iter. The two dependencies that import norm, x/net/idna and xdg-go/stringprep, only use String, Bytes and QuickSpan. So even the release branches that still ship an unfixed x/text have no path to this bug that I could find. This last point is inferred from master's import graph, not re-checked per branch.

Branch	x/text	Has the fix
release-25.1 to 25.4	v0.21.0 to v0.28.0	no
release-26.1, 26.2	v0.31.0	no
release-26.3	v0.37.0	no
release-26.4, master	v0.41.0	yes

Other cockroach-facing packages, all verified unchanged in behavior:

• collate and language. Their data tables are byte-identical between the two versions. Only a doc comment changed. Collation order for COLLATE columns does not move.
• cases and norm data. v0.41.0 ships Unicode 17 tables, but behind a go1.27 build tag. CockroachDB builds with Go 1.26.6, so it still compiles the Unicode 15 tables. I hashed the output of all four normalization forms and upper/lower/title mapping for every code point plus about six thousand accent combinations under both versions. The digests are identical. Caveat for the future: when cockroach moves to Go 1.27, this same x/text version will silently switch to Unicode 17 data.
• secure/precis. Reaches cockroach only through the pgx client's SCRAM password prep, which uses the OpaqueString profile. The v0.41.0 fix is for the Nickname profile's buffer handling, CVE-2026-56851. Fix only, and not our profile.

Full list of upstream changes from v0.32.0 to v0.41.0

Twenty-one commits, grouped by release:

Release	Change	Note
v0.33.0	dependency bumps only
v0.34.0	Unicode 17 tables gated to go1.27; norm table repacked to keep a "maybe composes" flag; old per-Go-version files deleted; internal idna cleanup	data proven identical under Go 1.26
v0.35.0	go directive raised to 1.25	errors is already at go 1.25.0
v0.36.0 to v0.38.0	dependency bumps only
v0.39.0	the CVE-2026-56852 hang fix	the reason for this PR
v0.40.0	idna rejects punycode labels that encode plain ASCII	internal package; cockroach uses x/net's own copy of idna, so unaffected
v0.41.0	precis Nickname short-buffer fix, CVE-2026-56851	not used by cockroach

PR hygiene checks

• Checksums. The go.sum hashes in the PR match the Go checksum database and cockroach's own go.sum line for v0.41.0.
• Build and tests. On the PR head, go mod verify is clean, go mod tidy produces no drift, build and vet pass, and all 22 test packages pass. One gotcha if you rerun: the withstack test asserts the clone path contains /errors/, so it fails from a directory like /tmp/crdb-errors-pr168 for reasons unrelated to the PR.
• PR claim about Go versions. Correct. v0.42.0 requires go 1.26.0, v0.41.0 requires go 1.25.0.
• One correction to the PR text. "No package in this module imports it directly" is true, but x/text's language and cases packages are compiled into errors' build through sentry-go, and norm through x/net/idna. Harmless, just imprecise.

[rharding6373]

TFTR!