Move to a three-node cluster with a Talos VIP; add Longhorn

Every node is now both control plane and worker, giving real tolerance
for losing any single machine (etcd quorum needs 3, not 1). A Talos VIP
gives the cluster one stable address regardless of which node answers.

Also pre-installs Longhorn for replicated storage, backed by a Talos
UserVolume on each node's second disk (>=900GB, non-system) rather than
the default path — mirroring the pattern from the homescale repo.

Docs renumbered to make room for 06-longhorn.md; checklist, glossary,
network map, and CLAUDE.md's guided-bootstrap instructions updated to
match, including asking the user for node IPs, VIP, and disk info before
generating any Talos config.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

talos/patch-controlplane.yaml

@@ -1,15 +1,43 @@
 # A patch applied on top of the controlplane.yaml that `talosctl gen config`
 # produces (see talos/README.md and docs/02-talos-bootstrap.md for the full
-# command). Talos's generated defaults assume a multi-node cluster where
-# control-plane nodes only run the Kubernetes control plane itself (API
-# server, scheduler, etcd, etc.) and never your actual workloads. For a
-# single-node learning cluster, that would mean nothing can ever be
-# scheduled — there's no other node to run it on.
+# command). Applied identically to all three control-plane nodes.
 #
-# This one field undoes that restriction, letting the single node be both
-# the control plane AND a worker.
+# --- allowSchedulingOnControlPlanes ---
+# Talos's generated defaults assume control-plane nodes only run the
+# Kubernetes control plane itself (API server, scheduler, etcd, etc.) and
+# never your actual workloads — normal practice, so a workload crashing
+# never has a chance to take the control plane down with it. This repo's
+# three nodes are deliberately both control plane AND worker at once (no
+# separate worker nodes), to get real multi-node resilience without needing
+# more than three machines. This one field undoes the default restriction.
 #
 # >> Ask Claude: "why does Kubernetes normally keep workloads off control
-#    plane nodes?" if you want the reasoning before you turn it off.
+#    plane nodes, and what am I giving up by turning that off here?" if you
+#    want the reasoning before you turn it off.
+#
+# --- vip ---
+# With three control-plane nodes, "the cluster's API server" isn't one
+# fixed machine anymore — it's whichever of the three happen to be up.
+# Talos's VIP (Virtual IP) feature solves this: the three nodes
+# continuously elect one of themselves to answer on this one shared
+# address, and re-elect within seconds if that node goes down. Point
+# everything that talks to the cluster (talosctl, kubectl, this repo's
+# Application manifests) at the VIP, never at one node's own address —
+# that's what makes losing any single node a non-event instead of an
+# outage.
+#
+# Replace both the interface name and the IP below with your real values
+# before generating config — see docs/02-talos-bootstrap.md.
+#
+# >> Ask Claude to help you pick the VIP address — like the MetalLB pool in
+#    docs/05-metallb.md, it has to be a real, unused address on your LAN,
+#    outside your DHCP range.
 cluster:
   allowSchedulingOnControlPlanes: true
+machine:
+  network:
+    interfaces:
+      - interface: eth0 # EDIT ME — match your node's real NIC name (`talosctl get links --insecure --nodes <NODE_IP>` from maintenance mode will show it)
+        dhcp: true
+        vip:
+          ip: 192.168.1.239 # EDIT ME — replace with your chosen VIP address