feat(scale): add command to scale up/down node groups

[akrem-chabchoub]

Summary

Adds a beekeeper scale command that reconciles a single node group in an already-running Bee cluster to a desired node count, without redeploying or touching the rest of the cluster.

This will support the investigations in ethersphere/bee#5396.

Today, growing or shrinking a node group means hand-editing count: in the cluster config and re-running create bee-cluster, which walks every node group in the cluster. scale targets one node group directly and only acts on the nodes that actually need to change.

How to run

./dist/beekeeper scale \
  --cluster-name local-dns \
  --node-group bee \
  --count 16

Flags:

• --cluster-name (required) — cluster to operate on, must already exist and be running
• --node-group (required) — the node group to scale (e.g. bee, light)
• --count (required) — desired final node count for that group
• --timeout (optional, default 30m)

Behavior — the group's nodes are named <node-group>-0, <node-group>-1, ...:

• count > current size → deploys the missing nodes, growing from the last index (e.g. 8 → 16 deploys bee-8 .. bee-15)
• count < current size → deletes the highest-indexed nodes down to count (e.g. 16 → 8 deletes bee-15 .. bee-8), including each node's PVC if persistence is enabled for the group
• count == current size → no-op

Current size is never taken from the YAML config — it's discovered live by probing the cluster (StatefulSet.Exists from index 0 upward until one is missing), so scale is safe to re-run and self-corrects after a partially completed previous run.

Current limitations

• No funding. scale only deploys/deletes Kubernetes resources — it does not fund new nodes with ETH/BZZ. New nodes come up unfunded; beekeeper node-funder must be run manually afterward to top them up. See the follow-up note below.
• Bootnode node groups are not supported. Any node group with mode: bootnode is rejected outright. Bootnode groups use an explicit nodes: list (always a single bootnode-0) rather than a count:, and every other node group depends on its address for peer discovery — there's no sensible grow/shrink model for it. Use delete bee-cluster if the bootnode itself needs to go.
• No explicit-node groups. Node groups configured with an explicit nodes: list (instead of count:) are rejected — scale only supports count-based groups.
• No --node-group all. Each node group must be scaled independently, one command per group; there's no bulk "scale everything" option.
• Sequential existence probing. Determining the current size does one Get per index (0, 1, 2, ...) until a miss, rather than a single List call — fine at today's node counts, but worth revisiting if node groups grow very large.

Follow-up needed: node-funder should support autofunding

Because scale doesn't fund new nodes, the current workflow is two manual steps (scale then node-funder).

[akrem-chabchoub]

Current delete cmd looks at the spec in the local.yaml and delete nodes based on that, but after we scale up/down the number of nodes is changed so the delete cmd is not working properly.

Suggestion: make the delete cmd looking to the cluster state not the file state.

---

Later support helm deployment, storage persistence (needed in the real cluster not locally)