Bump golang.org/x/net and golang.org/x/text in api

[oskarhurst]

Bumps the two api dependencies that the Go toolchain bump in #785 could not reach.

These were deliberately excluded from #785 because they need a regenerated go.sum, and Go
was not installed on the machine that PR was prepared on. It is now, so this PR closes that
gap — and unlike the previous four, this one is build-verified.

Changes

Package	From	To	Minimum required	Why
golang.org/x/net	v0.55.0	v0.58.0	0.56.0 (#691)	direct dependency
golang.org/x/text	v0.38.0	v0.41.0	0.39.0 (#701)	indirect
golang.org/x/crypto	v0.53.0	v0.55.0	—	pulled by the graph
golang.org/x/sync	v0.21.0	v0.22.0	—	pulled by the graph
golang.org/x/sys	v0.46.0	v0.47.0	—	pulled by the graph

Why past the stated minimum

The scan asks for x/net >= 0.56.0 and x/text >= 0.39.0. Both go to the current release
instead. Stopping at the minimum is what forces a second bump the following week — the same
trap #637 hit, where three CVEs needed >= 1.26.4 and two needed >= 1.26.5. The extra headroom
costs nothing here and the build is verified below.

x/crypto, x/sync and x/sys moved because the module graph requires them, not by choice.
They are included so go.mod and go.sum stay internally consistent — go mod tidy would
produce this regardless.

Testing

Run locally with Go 1.26.7, using the exact flags from api/Dockerfile
(GOOS=linux GOARCH=amd64 CGO_ENABLED=0):

Check	Result
go mod verify	all modules verified
go build ./...	clean, exit 0
go vet ./...	exit 1 — see below

go vet fails, but it fails identically on unmodified cwbi-dev, so it is pre-existing
and unrelated to this change. I verified by stashing the go.mod/go.sum edits and re-running:

models\download.go:50:2: struct field StatusID repeats json tag "status_id" also at download.go:28

That is a duplicate JSON tag in api/models/download.go — the status_id key is declared
twice on the same struct, so one silently wins during marshalling. Worth fixing, but it is not
this PR's to fix and bundling it would muddy a security change. Flagging it rather than
touching it.

Still gate on cwbi-test-build-push-api; a local build is not a substitute for the real image
build.

Related issues

Deliberately Refs, not Closes. Both issues also list pg_featureserv, which is not fixed
by this PR — #786 removes it, and the deployed service has to be deprovisioned before either
issue is genuinely resolved.

Refs USACE/cumulus-issue-tracking#30, refs USACE/cumulus-issue-tracking#39

Issue	Severity	Package	Status after this PR
USACE/cumulus-issue-tracking#30	HIGH	go/stdlib, golang.org/x/net	api and async_listener done (#785 + this). async_geoprocess/async_packager done in #783. Remaining: pg_featureserv.
USACE/cumulus-issue-tracking#39	HIGH	golang.org/x/text	api done here. async_geoprocess/async_packager done in #783. Remaining: pg_featureserv.

Once #786 merges and the service is deprovisioned, both can be closed by hand.

What this leaves

After this, the only fix:code-repo work still outstanding is:

• #773 (h2 4.3.0 -> 4.4.1, MEDIUM) — the async_packager half is a pin in
  setup.cfg; the async_geoprocess half lives in USACE/cumulus-geoproc, a separate repo.
• #626 / USACE/cumulus-issue-tracking#5 (github.com/aws/aws-sdk-go v1, MEDIUM/LOW) — no upstream fix exists.
  Never patched on the v1 line; the fix is only in the v2 encryption client. Arrives indirectly
  via go-simple-asyncer. Either drop the dependency or risk-accept — the vulnerable
  s3crypto package is not imported anywhere, so risk acceptance looks defensible, but it
  should be written down rather than left implicit.