millenia: nightly encrypted backup, supervision, and hardened Piper units

The canonical instance -- the one with her actual writing -- turned out
to be the least protected thing in the estate:

- No scheduled backup at all; the newest snapshot was a month old. Now
  petal-backup.timer: VACUUM INTO, gzip, age-encrypt with the parodia
  public recipient, push to the VPS over headscale with a size check,
  prune both ends. Persistent=true because the box is not on 24/7.
  Neither machine can decrypt what it holds; the identity is offline.

- Petal ran as a bare ./petal with PPID 1, so a crash or reboot left it
  down until somebody noticed. Now petal.service, verified by kill -9.

- The Piper units retried forever without ever failing: RestartSec=3
  against systemd's default 10s window means the burst limit is never
  reached, which is how a dead service logged 26,800+ restarts over a
  day while read-aloud silently fell back to browser speech.
  StartLimitIntervalSec=300 makes a broken Piper show up in --failed.

backup-petal.sh now handles both deployment shapes (compose exec on the
VPS, local binary on millenia) and encrypts before anything leaves the
host. The VPS no longer uses it -- Petal rides parodia-backup there.

deploy/piper-zh.service

@@ -2,6 +2,14 @@
 Description=Piper TTS HTTP server — Chinese voice (read-aloud backend for petal)
 After=network-online.target
 Wants=network-online.target
+# Give up loudly instead of retrying forever. This service once failed 26,800+
+# times over a day without anyone noticing: RestartSec=3 means only ~3 restarts
+# land inside systemd's default 10s StartLimitIntervalSec, so the default burst
+# of 5 was never reached and the unit never entered `failed`. Widening the
+# window to 5 minutes makes a genuinely broken Piper show up in
+# `systemctl --user --failed` while still riding out transient blips.
+StartLimitIntervalSec=300
+StartLimitBurst=5
 
 [Service]
 Type=simple