restore full dump flags; stop spurious alerts claiming FAILED

mariadb-upgrade --force has now been run against both instances and repaired
the system tables, so --routines and --events no longer abort the dump.
Restore them for completeness. Both verified: rc=0 with a clean completion
trailer, and both Nextcloud instances report installed with unchanged table
counts afterwards.

The upgrade still exits non-zero on these containers because it cannot create
the `sys` schema: /var/lib/mysql is owned by daemon rather than mysql, so
mysqld may not create top-level databases. `sys` is diagnostic only and
unused by Nextcloud, but the same permission would block creating any new
database, so it is recorded in the template comment.

The alert handler claimed FAILED in its subject line regardless of what the
unit actually reported, so starting it by hand mailed out a failure notice
for a run that succeeded. Derive the subject and log line from the real
Result, and emit status=spurious rather than status=failed so such triggers
cannot match a Graylog alert rule keyed on genuine failures.

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

ansible/roles/podman/templates/nextcloud/cloud-backup.sh.j2

@@ -40,11 +40,17 @@ log "status=start"
 # $MYSQL_ROOT_PASSWORD and $MYSQL_DATABASE are expanded by the shell INSIDE
 # the database container, which already carries them in its environment.
 #
-# Flags are deliberately minimal. --events and --routines were both tried and
-# both abort the dump on these instances: the event scheduler is disabled
-# (error 1577) and mysql.proc reads as corrupted (error 1728, an artefact of
-# an image bump without mariadb-upgrade). Nextcloud uses neither events nor
-# stored routines, so dropping them loses nothing.
+# --routines and --events initially aborted the dump here: mysql.proc read as
+# corrupted (error 1728) and the event scheduler reported disabled (1577),
+# both artefacts of an image bump without mariadb-upgrade. `mariadb-upgrade
+# --force` has since been run against both instances and repaired the system
+# tables, so the full flag set works and is kept for completeness.
+#
+# Note that upgrade still exits non-zero on these containers: it cannot
+# install the `sys` schema because the datadir root (/var/lib/mysql) is owned
+# by daemon rather than mysql, so mysqld may not create new top-level
+# databases. `sys` is purely diagnostic and unused by Nextcloud, so this is
+# cosmetic -- but it does mean creating a NEW database would fail too.
 pexec() {
   sudo -H -u {{ podman_user }} bash -c \
     'cd; d=/run/user/$(id -u); [ -d "$d" ] && export XDG_RUNTIME_DIR="$d"
@@ -59,7 +65,7 @@ log "dumping {{ db_container }}"
 set +e
 pexec exec {{ db_container }} sh -c '
   exec env MYSQL_PWD="$MYSQL_ROOT_PASSWORD" mariadb-dump -u root \
-    --single-transaction --quick --triggers \
+    --single-transaction --quick --routines --events --triggers \
     --no-tablespaces --default-character-set=utf8mb4 "$MYSQL_DATABASE"
 ' | gzip -6 > "$tmp"
 dump_rc=${PIPESTATUS[0]}