deps: clear x/text DoS advisory and unstale the vm-compat Go pin

[palango]

Two follow-ups for #476, based directly on its head so it fast-forwards.

1. golang.org/x/text v0.36.0 → v0.40.0

The toolchain bump landed x/text on v0.36.0, which is affected by GO-2026-5970: norm.Iter enters an infinite loop on invalid UTF-8. govulncheck reports it as symbol-reachable (norm.Form.Properties) in the op-node and op-batcher binaries — the same unbounded-loop DoS class Issue A set out to remove, so it seemed wrong to leave it behind in the PR that closes the others.

Fixed in v0.39.0; this takes the latest v0.40.0. MVS pulls the sibling golang.org/x/* modules up with it, which also moves x/net v0.53.0 → v0.56.0 and so clears GO-2026-5026 (idna.ToASCII, likewise symbol-reachable).

Go itself is left at 1.26.4. Bumping to 1.26.5 (upstream develop is already there) would additionally clear GO-2026-5856, but that is a bigger change than this PR wants to carry — worth doing separately.

2. vm-compat Go pin

op-program/Dockerfile.vmcompat and the two op-program/justfile recipes still pinned golang:1.24.10-alpine3.21 while the root go.mod now requires go >= 1.26. That image sets GOTOOLCHAIN=local, so its go mod download fails — the identical breakage already fixed for Dockerfile.repro in d95c361. Upstream deleted op-program from the monorepo, so its toolchain bump never had to touch these.

Not a CI break: analyze-op-program-client and op-program-compat are commented out on this fork. It only affects just run-vm-compat / just regenerate-vm-compat-baseline locally. The commented-out "next" build stays on 1.25.4 — its TODO(#18334) is about vm-compat's own go1.25 support, not the toolchain.

Verified

Run against this branch with Go 1.26.4:

go build ./...                                              exit 0, no output
go vet (op-node, op-batcher, op-service, op-chain-ops,
        op-proposer, op-challenger)                         exit 0, no output
go mod tidy -diff                                           exit 0, empty
go test -short ./op-service/... ./op-node/rollup/derive/...  exit 0, 0 failures
govulncheck -mode=binary (op-node)                          11 -> 9 reachable

Tests cover the packages that actually touch the bumped modules: op-service/client (the RPC dialer on the L1 path), op-service/sources, op-service/txmgr, and op-node/rollup/derive (Espresso batch authentication).

After the change, GO-2026-5970 no longer appears, and neither do GO-2026-4870 / 4918 / 5037. The nine that remain are pre-existing and outside Issue A: quic-go x3, webtransport-go x3, pion/dtls (no fix available), otel baggage, and GO-2026-5856 (needs Go 1.26.5).

Note on the fix narrative in #476

Minor correction for the record: in the pre-bump scan, x/net's GO-2026-4918 entry has zero vulnerable symbols — module-level only. The symbols actually found are in stdlib net/http, which vendors its own http2 as net/http/internal/http2, and nothing in the repo imports golang.org/x/net/http2 directly. So the toolchain bump is what closes the live HTTP/2 path; the x/net bump is defence-in-depth. Worth knowing so nobody later concludes that keeping x/net current is sufficient on its own.

[philippecamacho]

Thanks for catching these version mismatches.