[Rust roadmap] Client contract fixtures and loader baseline benchmarks (Java as the compatibility reference) #772

Parent: #748, checklist items "Define the compatibility matrix and shared test fixtures" and "Publish baseline benchmarks against the current implementation".

Scope

1. Client contract fixtures. A language-neutral set of JSON files, one per REST call: method, path, the headers that matter for the contract, request body, expected status and response shape (required fields, types, constant values). The first version covers the "minimal client" from [Roadmap] Incremental Rust modernization for HugeGraph Toolchain #748: /versions, auth (basic and token), schema (property key, vertex label, edge label, index label), graph (vertex, edge, batch, batch update with strategies), gremlin. Versioned per server API version. The source of truth is the behaviour of the Java client against the server commit pinned in CI: the fixtures are recorded from the Java client (an interceptor in RestClient that writes the request and the response), not written by hand, so they cannot drift from the code.
2. Runners. Java: a test in hugegraph-client that replays every fixture through the client and checks that the request sent and the parsed response match the file. Go: the same set through hugegraph-client-go; endpoints without an implementation are reported as unsupported, not as failures. The output is a Java/Go parity matrix generated in CI (markdown in the job artifacts), the first version of the "compatibility matrix" from the checklist.
3. Loader baseline benchmark. A script and a deterministic data generator (parameterised size; CI profile: 100k vertices / 500k edges, full profile: 5M / 25M), loading through hugegraph-loader on rocksdb and on hstore, metrics: rows/s, p50/p99 batch time, loader RSS and heap, startup time, time to resume after a SIGKILL half-way (resumability), retry count. Results as markdown in the repo with hardware, server and loader versions, plus raw logs. First publication from my 3-node k3s cluster (Helm chart from feat(helm): add HStore deployment chart hugegraph/hugegraph#221) and from the CI runner for the small profile.

Non-goals

• No Rust code in this issue; no change to the behaviour of the Java client or the loader (the fixtures describe what is there, including the rough edges; Java/Go divergences become separate issues).
• No traversers, auth management, graph spaces or Vermeer in the first version; they follow once the format holds.
• No server benchmarks; the loader is measured as a client.

Compatibility

The fixtures are test data, not an API; they live in hugegraph-dist/contract/ (or a separate hugegraph-contract module, to be decided in the PR) and are consumed by tests in the existing client-ci and client-go-ci jobs, against the same pinned server commit. A new server API version is a new fixture directory; old ones stay.

Acceptance criteria

• The Java runner passes in client-ci on all three Java versions; the Go runner passes in client-go-ci with the parity matrix in the artifacts.
• Re-recording the fixtures from the same server commit yields identical files (determinism: ids and timestamps normalised).
• The benchmark script reproduces the CI-profile result with a single command; the published full-profile numbers come with logs and configuration.
• docs/contract-tests.md: how to record, how to add an endpoint, how to plug in a new language.

PR plan