Align 09-growing-up with actual control-plane/worker split

docs/09-growing-up.md

@@ -7,24 +7,43 @@ for you; each is its own project once you're ready.
 
 ## More nodes
 
-Your three nodes already give you real resilience — losing any one still
-leaves a majority of control-plane voters (see
-[`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md#three-nodes-each-both-control-plane-and-worker))
-and, once Longhorn has real volumes, a replica of your data likely
-survives too. Growing further is about *capacity*, not fault tolerance you
-don't already have — so beyond this point, add plain **worker** nodes, not
-more control-plane ones:
+This cluster already separates roles — three Raspberry Pi control planes
+(`talos-455-i3b`, `talos-9xy-iuk`, `talos-k1b-7j5`) and two Proxmox
+workers (`talos-rss-v5l` on Gimli, `talos-vba-ood` on Titus; see
+[`docs/network.md`](network.md) for current addresses). Losing any one
+control plane still leaves a majority of etcd voters, and losing either
+worker still leaves one healthy Longhorn replica of any volume that had
+data on it. Growing further is about *capacity*, not fault tolerance you
+don't already have — so beyond this point, add another plain **worker**,
+not a fourth control plane.
 
-1. Boot a new machine from the same custom Talos ISO as the first three
-   (see [`docs/01-prerequisites.md`](01-prerequisites.md)).
-2. Apply the **worker** config instead of the control-plane one — you
-   already have `_out/worker.yaml` from
-   [`docs/02-talos-bootstrap.md`](02-talos-bootstrap.md), unused until now:
+1. Boot the new machine from a Talos image matching its own architecture
+   — `rpi_generic` (arm64) for another Raspberry Pi, or the amd64 metal
+   image for another x86 machine/VM. Both custom schematics already exist
+   for this cluster — see [`talos/patch-controlplane.yaml`](../talos/patch-controlplane.yaml)
+   and [`talos/patch-worker.yaml`](../talos/patch-worker.yaml) for the
+   exact installer image references, and
+   [`docs/01-prerequisites.md`](01-prerequisites.md) for building a new one
+   if this is a genuinely new architecture/extension set.
+2. Generate (or reuse, if unchanged) a worker config with both
+   `talos/patch-worker.yaml` and `talos/patch-longhorn.yaml` applied, then
+   apply it to the new node:
    ```sh
    talosctl apply-config --insecure --nodes <NEW_NODE_IP> --file _out/worker.yaml
    ```
-3. `kubectl get nodes` should show a fourth node shortly after, without
-   the `control-plane` role.
+3. If this node will also provide Longhorn storage, give it its own
+   dedicated data disk sized to fit `talos/patch-longhorn.yaml`'s
+   `minSize`, and label it the same way
+   [`talos/patch-worker.yaml`](../talos/patch-worker.yaml) labels the
+   existing two workers — `node.longhorn.io/create-default-disk=true` —
+   or Longhorn will never offer it a disk.
+4. `kubectl get nodes` should show the new node shortly after, without the
+   `control-plane` role. With a third storage-providing worker, consider
+   raising Longhorn's `defaultReplicaCount` and
+   `persistence.defaultClassReplicaCount` in
+   [`apps/longhorn/values.yaml`](../apps/longhorn/values.yaml) from `2` to
+   `3` — see [`docs/06-longhorn.md`](06-longhorn.md) for why both settings
+   have to move together.
 
 ### Why not a fourth control-plane node