docs: correct migration records that outlived their migrations

Both documents described work as outstanding that the cluster shows finished.
A record that says "REMAINING" long after the fact is worse than no record:
it is read as current state, and the next person plans around it.

## Home Assistant recorder

Phase 2c is done, and done correctly. Against the live database:

  statistics             11,092,586   2024-03-13 20:00 -> current
  statistics_short_term   1,883,709   rolling ~7 days
  statistics_meta             1,480

The 2024-03-13 origin is the part that matters. It is unchanged from the
10,793,712-row count recorded on 2026-08-19, so the history was copied across
engines rather than started from zero — the exact failure the document was
written to prevent. `states` carries current rows, so db_url points at
Postgres.

The three "INERT"/"PHASE 1" comments went with it. All three described a
cluster that nothing consumed; it is now the recorder's live database, and the
render-db-url init container is load-bearing rather than inert — HA will not
start without the secret it renders.

## Bare-metal conversion

`talosctl get systeminformation` reports Minisforum MS-01 hardware with
distinct chassis serials for all three nodes and no hypervisor, so saturn and
neptune are not outstanding. Node creationTimestamp is not evidence either way:
k8s-3 still carries its 2026-05-09 object and is on metal regardless.

The runbook stays as the procedure for a rebuild.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubernetes/RUNBOOK-baremetal-conversion.md

@@ -2,7 +2,12 @@
 
 Converts one MS-01 from "Proxmox host running a Talos VM" to "Talos on bare
 metal", and swaps its Ceph OSD onto a Samsung PM983 at the same time. Written
-after doing jupiter on 2026-08-25; saturn and neptune remain.
+after doing jupiter on 2026-08-25.
+
+All three nodes are now on bare metal — `talosctl get systeminformation`
+reports Minisforum MS-01 hardware with distinct chassis serials for k8s-1,
+k8s-2 and k8s-3, with no hypervisor in between. Kept as the procedure for a
+rebuild, not as outstanding work.
 
 Everything here that reads like an over-specific warning is something that
 actually happened. The conversion itself is straightforward — the failures were

kubernetes/apps/home-assistant/MIGRATION-recorder-postgres.md

@@ -111,9 +111,23 @@ statistics             max_id=13323904    max_start_ts=1787162400.0
 statistics_short_term  max_id=159205762   max_start_ts=1787166000.0
 ```
 
-## Phase 2c — cutover (REMAINING)
+## Phase 2c — cutover: DONE
 
-Do not start until phase 1 is verified.
+Verified 2026-09-02 against the live database:
+
+| table | rows | span |
+|---|---|---|
+| `statistics` | 11,092,586 | 2024-03-13 20:00 → current |
+| `statistics_short_term` | 1,883,709 | rolling ~7 days |
+| `statistics_meta` | 1,480 | |
+
+The 2024-03-13 origin is the proof that matters. It is unchanged from the
+pre-migration count in "What is at risk" above, so the history was copied
+across engines rather than started from zero — which is the failure this
+document exists to prevent. `states` carries current rows, so `db_url` points
+at Postgres.
+
+The procedure below is kept as the record of what was done.
 
 **Migrate statistics only.** Copying all 18M `states` rows is slow, needs a long
 HA outage, and buys a table that is discarded within 7 days anyway.

kubernetes/apps/home-assistant/deployment.yaml

@@ -56,10 +56,9 @@ spec:
         # Re-rendered on every pod start, so a CNPG password rotation takes
         # effect rather than silently leaving a stale URI behind.
         #
-        # INERT until the recorder is repointed: nothing reads this key until
+        # Load-bearing: `db_url: !secret recorder_db_url` in the homeassistant
-        # `db_url: !secret recorder_db_url` lands in configuration.yaml in the
+        # repo's configuration.yaml reads this key, so HA does not start
-        # homeassistant repo. That ordering is required — HA refuses to start
+        # without it. Removing this init container takes the recorder down.
-        # when a referenced secret is missing.
         - name: render-db-url
           image: busybox:1.36
           command:

kubernetes/apps/home-assistant/ha-pg-cluster.yaml

@@ -18,12 +18,12 @@
 # That is the point of the move — it attacks the multiplier rather than trimming
 # what gets recorded, which would only hide the problem.
 #
-# STAGING
+# This is the live recorder database. HA writes here; the SQLite file is no
-# Phase 1 (this manifest): the cluster comes up EMPTY and HA keeps using SQLite.
+# longer the system of record. The 2.4 years of long-term statistics were
-# Nothing depends on it, so a failure here is inert. Verify Ready, WAL archiving
+# copied across engines rather than regenerated — HA does not migrate data
-# to Hetzner, and a successful base backup before going further.
+# between database engines, so an empty Postgres would have silently started
-# Phase 2: migrate the statistics tables and repoint recorder.db_url.
+# from zero and taken the energy dashboard's history with it.
-# See MIGRATION-recorder-postgres.md for the sequence and the rollback.
+# MIGRATION-recorder-postgres.md holds the sequence that was followed.
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:

kubernetes/apps/home-assistant/kustomization.yaml

@@ -60,9 +60,8 @@ resources:
   - zigbee2mqtt-gate-service.yaml
   - zigbee2mqtt-ingress.yaml
   # Postgres backend for the recorder (MIGRATION-recorder-postgres.md).
-  # PHASE 1: this cluster comes up EMPTY and nothing consumes it — HA is still
+  # Live: recorder.db_url in the homeassistant repo points here, and the
-  # on SQLite. Deploying it is therefore inert; phase 2 migrates the statistics
+  # long-term statistics carry their full history from 2024.
-  # tables and repoints recorder.db_url in the homeassistant repo.
   - ha-pg-hetzner-creds-externalsecret.yaml
   - ha-pg-objectstore.yaml
   - ha-pg-cluster.yaml