pyln: relax the grpcio/protobuf pins and regenerate the protos

[cdecker]

Summary

grpcio, grpcio-tools and protobuf were hard-pinned to exact versions, which kept the
tree off every newer release. Relax them to floors and regenerate the checked-in stubs with
the resulting toolchain.

Why the floors move up

This looks backwards for a change whose point is to relax pins, so it is worth spelling out.
Generated protobuf code asserts runtime >= gencode at import time, and the grpc stubs
refuse to load below the grpcio-tools that produced them. Regenerating therefore raises the
minimum, and the manifests have to say so or a fresh install resolves an older runtime and
dies on import rather than at some later, stranger point:

• protobuf >= 6.33.5 (was == 6.32.1)
• grpcio >= 1.81.1, grpcio-tools >= 1.81.1 (were == 1.75.1)

Comments next to each bound record that they must be bumped together with a regeneration.

The comment claiming the protobuf pin matched .github/scripts/setup.sh was stale; that file
carries no protobuf version.

Makefile fix

contrib/pyln-grpc-proto/Makefile invoked a bare python for the primitives.proto step,
which is not on PATH in the uv-managed environment, so make protos died with
make: python: No such file or directory after regenerating node.proto. The rule declares
primitives_pb2.pyi and node_pb2.pyi as outputs, but because the recipe aborted there they
were never produced and so were never checked in — even though the package ships py.typed.
Both stub files are now generated and committed.

Testing

cargo check --all is clean. pyln.grpc imports and round-trips a message against the
regenerated stubs on grpcio 1.83.1 / protobuf 6.33.6.

Note

cargo-udeps reports no unused dependencies anywhere in the workspace.

Separately, and not addressed here: the tree carries a duplicate HTTP stack
(reqwest 0.11 pulling hyper 0.14, h2 0.3, http 0.2, rustls 0.21) entirely from
plugins/bip353-plugin. The obvious fix — bitcoin-payment-instructions 0.7, which drops
reqwest for the much smaller bitreq — is not viable: bitreq's Proxy supports only
HTTP CONNECT, with no SOCKS support and no feature to add it. The plugin uses socks5h://
for Tor, where the h also prevents DNS leaks, so taking that upgrade would silently break
Tor for BIP-353 lookups. Worth revisiting if bitreq gains SOCKS.