[Roadmap] Incremental Rust modernization for graph computing

## Goal

Explore an **incremental Rust implementation** for selected graph-computing components in HugeGraph Computer and Vermeer, focusing on kernels, data movement, memory efficiency, and operational simplicity where Rust offers a measurable advantage.

This is a parent tracking issue, not a commitment to replace the existing Java/Go systems wholesale. Existing algorithms, formats, and deployments remain the compatibility and performance baseline.

## Roadmap at a glance

```text
Toolchain -> Server core -> HStore -> PD
│
v
┌─ This repository ─────────────────────────────────────────────┐
│ Baselines -> isolated kernel/I/O -> multi-worker validation │
│ │ │
│ v │
│ broader Vermeer/OLAP scope │
└───────────────────────────────────────────────────────────────┘

Expansion happens only when correctness and benchmark gates pass.
```

## Proposed priority

This work follows the shared Toolchain and Server foundations. Within this repository:

1. Establish representative graph datasets, algorithm outputs, and performance baselines for Computer and Vermeer.
2. Prototype a small isolated kernel or I/O component with a stable boundary.
3. Validate multi-worker behavior, determinism, failure recovery, and resource use before expanding scope.
4. Consider broader Vermeer/OLAP migration only after the experiments show a clear maintenance and performance benefit.

## Delivery model

```text
baseline -> proposal/RFC -> isolated kernel or I/O slice
-> result-parity + scale tests -> opt-in preview -> staged adoption
```

## Planning guardrails (required)

Before implementation starts, each child issue **must** define:

- scope, owner/mentor, and non-goals;
- API/CLI/config, protocol, input/output/storage-format, algorithm, and operational compatibility;
- differential result parity/tolerance, determinism, concurrency, multi-worker, fault-injection, and upgrade/rollback tests, where applicable;
- reproducible latency, throughput, memory, scaling, cost, and recovery benchmarks;
- security/dependency checks and supported platforms;
- observability, packaging/deployment, coexistence, migration, and rollback plans;
- explicit acceptance criteria and user/operator/contributor documentation.

No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage. Benchmark results must include datasets, hardware, configuration, and the current implementation used as the baseline.

## Candidate work items

- [ ] Define representative datasets and algorithm correctness fixtures
- [ ] Publish Computer and Vermeer performance/resource baselines
- [ ] Select one small proof-of-concept kernel or I/O path
- [ ] Decide the interoperability and packaging boundary
- [ ] Establish Rust CI, lint, dependency, and release conventions
- [ ] Validate local and multi-worker deployment paths
- [ ] Split approved work into newcomer-friendly child issues

This checklist will link to concrete child issues as proposals are accepted.

## Project-wide roadmap

- Toolchain: apache/hugegraph-toolchain#748
- Server / HStore / PD: apache/hugegraph#3110
- Computer / Vermeer (this issue): apache/hugegraph-computer#355
- Documentation hub: apache/hugegraph-doc#462

## How to participate

Interested in **open source, Rust, graph algorithms, distributed computing, performance engineering, or infrastructure**? Comment with the area you want to work on and any relevant experience. Algorithms, datasets, correctness tests, deployment work, and documentation are all useful entry points.

First-time contributors can start with the [HugeGraph contribution guide](https://hugegraph.apache.org/docs/contribution-guidelines/contribute/) and the repository's `good first issue` / `help wanted` tasks.

No implementation files, tests, or entry points are named; this is a parent roadmap rather than a directly actionable task. Start by reviewing the candidate work items and planning guardrails, then define a concrete child issue with an owner, scope, compatibility requirements, benchmarks, tests, and acceptance criteria. Done means an approved, bounded child proposal exists before implementation begins.

Written by the indexing model from the issue text.