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>

apps/demo/configmap.yaml

@@ -4,7 +4,7 @@
 # baking the page into a custom container image.
 #
 # Why this matters for the GitOps story: this is the file you'll edit in
-# docs/06-your-first-change.md. Change the text here, commit, push, and
+# docs/07-your-first-change.md. Change the text here, commit, push, and
 # watch Argo CD notice the difference in Git and push it into the cluster
 # for you — no `kubectl` command involved. That's the whole loop, proven
 # with one line of HTML.

apps/demo/deployment.yaml

@@ -2,7 +2,7 @@
 # serving this ConfigMap's index.html") and hands it to Kubernetes, whose
 # job is to continuously make reality match that description. If the Pod
 # crashes, Kubernetes restarts it. If the node dies, Kubernetes (given more
-# than one node — see docs/08-growing-up.md) reschedules it elsewhere.
+# than one node — see docs/09-growing-up.md) reschedules it elsewhere.
 # You never tell Kubernetes "start a container" directly; you describe the
 # end state and it does the work. This is what "declarative" means.
 apiVersion: apps/v1