Clients: generate per-language gRPC clients (Go, Python, C#)

[robfrank]

Parent: #4894

Motivation

Rounds out the gRPC performance tier for the same three breadth languages targeted on the HTTP side (Python, C#, Go), using native gRPC stubs (not Connect) since these are server-side/backend languages without the browser constraint.

Proposed design

• Tooling: buf generate with protoc-gen-go+protoc-gen-go-grpc (Go), grpcio-tools/protoc-gen-grpc-python (Python), Grpc.Tools (C#), wired into buf.gen.yaml from the proto-packaging issue.
• Publish: Go module (pkg.go.dev via module proxy, tagged release), Python package (PyPI, e.g. arcadedb-grpc-client), C# NuGet package (e.g. ArcadeDB.GrpcClient).
• Smoke test: extend e2e-python and e2e-csharp with gRPC-specific test files (new coverage, same pattern as the REST client issue's smoke tests — these two issues can share the same new e2e infrastructure investment). No existing e2e-go module — same gap noted in the REST fan-out issue; either add a minimal standalone Go test or fold into a shared decision about opening an e2e-go module.

Acceptance criteria

• All three clients generate cleanly via buf generate from the packaged proto.
• Python and C# clients have gRPC smoke tests (unary + streaming) in e2e-python/e2e-csharp.
• Go client has at least a minimal smoke test (location decided jointly with the REST fan-out issue's Go gap).
• Each package README states "auto-generated from ArcadeDB's proto, versioned to server release X.Y.Z."

Dependencies

Depends on the proto-packaging issue. Independent of the Connect-ES TS gRPC client issue (both depend on proto packaging but not on each other) — parallelizes with it.

Effort estimate

L — three languages, three registries, plus needing to resolve the streaming-RPC test story (InsertStream, InsertBidirectional, GraphBatchLoad) per language, which is more involved than the REST smoke tests.