create-template-vm: add k8s-upgrade pipeline SSH key to node cloud-init

New k8s nodes were only getting the personal `wizard` key in authorized_keys —
not the automated k8s-version-upgrade pipeline's key (Vault
secret/k8s-upgrade/ssh_key_pub). So a freshly provisioned node is invisible to
the upgrade chain (it SSHes in as `wizard` to drain+upgrade): node4/5/6 all hit
"Permission denied (publickey)" on 2026-06-17 and had to have the key pushed by
hand. Bake the public key into the cloud-init template so every new node gets it
on first boot.

(unattended-upgrades is already in this template — node4/node5 missed it only
because the LIVE PVE cloud-init snippet lagged this source: it deploys via a
Tier-0 `stacks/infra` apply that hadn't run since before their 2026-05-26
provision. Same lesson applies to THIS change — it reaches new nodes only after
`stacks/infra` is applied to refresh the snippet on the PVE host.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

modules/create-template-vm/cloud_init.yaml

@@ -8,6 +8,13 @@ users:
     sudo: ALL=(ALL) NOPASSWD:ALL
     ssh_authorized_keys:
       - ${authorized_ssh_key}
+      # k8s-upgrade pipeline key (matches Vault secret/k8s-upgrade/ssh_key_pub).
+      # The automated k8s-version-upgrade chain SSHes in as `wizard` to drain +
+      # upgrade each node; WITHOUT this a freshly-provisioned node is invisible
+      # to the upgrade pipeline (node4/5/6 hit exactly this — Permission denied —
+      # 2026-06-17). Hardcoded: it's a public key and the keypair is stable; if
+      # it's ever rotated, update this line and Vault together.
+      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIElH9x76UNA8UNxrxTjREYz4hz1fbCdRwAXbOkJ5FnSM k8s-upgrade-pipeline
     passwd: ${passwd}
     lock_passwd: false # enable passwd login
     shell: /bin/bash