cluster: make example presets build-from-local, add gravity_cli Makefile target

[Stumble]

Summary

Two ergonomics fixes discovered while following the cluster deployment docs end-to-end on a clean machine.

1. cluster/example/*/cluster.toml — change source from github-clone to local project_path

Every preset under cluster/example/ ships with:

source = { github = "Galxe/gravity-sdk", rev = "main" }

This tells deploy.sh to re-clone the SDK and cargo-build a second copy of gravity_node inside the runtime dir (e.g. /tmp/gravity-cluster-one/artifacts/Galxe_gravity-sdk-main/target/quick-release/), even when the user has already built the binaries at the top-level target/quick-release/ by running the top-level Makefile.

Observed consequences on a fresh Ubuntu 24.04 box:

• Second build takes ~15–20 min that the user already paid.
• Second build duplicates ~5 GB of target artifacts.
• On machines with < ~10 GB free, make deploy dies mid-build with error: No space left on device (os error 28) — users can't figure out why because the outer build already succeeded.

The default cluster/cluster.toml.example already uses source = { project_path = \"../\" } — this PR brings the five cluster/example/*/cluster.toml files in line. The presets are named gravity-devnet-one, gravity-devnet-three, etc., so local-build is clearly the intended use case. Anyone deploying from github source can still flip the line back.

Files changed:

• cluster/example/1_node/cluster.toml
• cluster/example/1_node_distinct_roles/cluster.toml
• cluster/example/3_node/cluster.toml
• cluster/example/3_node_1_vfn/cluster.toml
• cluster/example/3_node_distinct_roles/cluster.toml

2. Makefile — add gravity_cli target (and a cluster convenience target)

init.sh, genesis.sh, and deploy.sh all resolve gravity_cli via find_binary and fail with `gravity_cli not found! Please build it first.` if it hasn't been built. But the Makefile has no target for it — only gravity_node, bench, and kvstore. So the documented build incantation

```
make BINARY=gravity_node MODE=quick-release
```

produces a broken setup: the next step (make init or make genesis) immediately fails. Users have to either read the scripts and discover the missing cargo build -p gravity_cli step, or stumble through the error.

This PR:

• Adds a gravity_cli Makefile target mirroring the other binary targets.
• Adds a cluster convenience target that builds both gravity_node and gravity_cli in one go — the minimum set of binaries needed to run any cluster deployment.
• Adds gravity_cli to BIN_DIRS so make clean covers it too.

With this change the cluster docs can simplify to a single make cluster MODE=quick-release step that actually works out of the box.

Test plan

• make cluster MODE=quick-release produces both binaries under target/quick-release/
• make -C cluster init && make -C cluster genesis && make -C cluster deploy_start with the 1_node preset succeeds against the local build (no remote re-clone, no second build)
• RPC responds on 127.0.0.1:8545 with eth_chainId = 0x539
• Existing multi-validator examples (3_node, 3_node_1_vfn, 3_node_distinct_roles) still deploy cleanly

🤖 Generated with Claude Code

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove the stale label, comment or push a commit - otherwise this will be closed in 15 days.