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-longhorn.yaml

@@ -0,0 +1,60 @@
+# Prepares each node for Longhorn (apps/longhorn.yaml) — the storage layer
+# this repo ships pre-installed. Applied identically to all three
+# control-plane nodes, alongside patch-controlplane.yaml.
+#
+# This file has TWO documents (separated by `---`), because it's making two
+# different kinds of change: a patch to the normal machine config, and a
+# standalone Talos resource that doesn't live inside `machine:`/`cluster:`
+# at all.
+#
+# --- Document 1: mount the volume into the kubelet's view ---
+# Talos runs the kubelet in its own isolated mount namespace. Without this,
+# a volume mounted at /var/mnt/longhorn on the node itself would be
+# invisible to any Pod using a hostPath-style mount there — which is
+# exactly how Longhorn's own manager and engine Pods access node storage.
+# This bind-mounts that same path into the kubelet's namespace so Pods can
+# actually see it. `rshared` matters specifically: it lets mounts Longhorn
+# creates later *underneath* this path (one per volume) propagate back out
+# to the host, instead of being invisible outside the container that made
+# them.
+#
+# --- Document 2: UserVolumeConfig ---
+# A Talos UserVolumeConfig tells Talos itself to find, format, and mount a
+# disk — no manual partitioning on your part. `diskSelector.match:
+# '!system_disk'` means "any disk that isn't the one Talos is installed
+# on" (never touches your OS disk), and `minSize: 900GiB` means "only
+# consider disks at least that large" — so if a node has more than one
+# extra disk, Talos won't accidentally pick a small one. Adjust `minSize`
+# if your nodes' data disks are smaller than 900GiB; just make sure it's
+# still large enough to exclude anything that *isn't* meant for Longhorn.
+# `grow: false` keeps the volume at its initial size even if the
+# underlying disk is later resized — deliberate here, so growing storage
+# is always a conscious decision (see docs/09-growing-up.md).
+#
+# The `name: longhorn` below is what determines the mount path Talos uses
+# — user volumes are always mounted at /var/mnt/<name>, which is why
+# Document 1 above and apps/longhorn/values.yaml both hardcode
+# /var/mnt/longhorn. Renaming this would mean updating both.
+#
+# >> Ask Claude: "how do I find out which of my disks Talos will actually
+#    pick for this?" before you boot for real — worth confirming on your
+#    specific hardware rather than assuming.
+machine:
+  kubelet:
+    extraMounts:
+      - destination: /var/mnt/longhorn
+        type: bind
+        source: /var/mnt/longhorn
+        options:
+          - bind
+          - rshared
+          - rw
+---
+apiVersion: v1alpha1
+kind: UserVolumeConfig
+name: longhorn
+provisioning:
+  diskSelector:
+    match: "!system_disk"
+  minSize: 900GiB
+  grow: false