fix(svc-db-mariadb): decouple the healthcheck from the root password

The container healthcheck logged in as root with MARIADB_ROOT_PASSWORD, so
it asserted two things at once: that the server is up, and that the root
credential matches. MariaDB only applies MARIADB_ROOT_PASSWORD while the
data directory is empty, so any later credential regeneration left the
container permanently unhealthy while every application user kept working.

That mixing produced a deadlock. sys-svc-compose waits for database health
before the play reaches svc-db-mariadb, but the repair for a drifted root
password lives in tasks/02_reset_root_password.yml, which runs after that
gate. The repair could therefore never run when it was needed: a failed
round showed the health wait retrying 65 times with the reset reached 0
times, while the round with this change reached the reset and root logins
worked again afterwards.

Use the credential-free check the image ships instead. It authenticates as
the mysql system user over the unix socket, so health answers only "is the
server up?". The credential question stays covered by the role itself:
tasks/00_core.yml probes the desired root login, includes the reset on
mismatch, and then waits until MariaDB accepts root credentials.

Verified against a container Docker reported as unhealthy: the new command
exits 0 there, and after the deploy the container came up healthy with it.

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

roles/svc-db-mariadb/templates/compose.yml.j2

@@ -20,7 +20,7 @@
     healthcheck:
       test:
         - "CMD-SHELL"
-        - "mariadb {% if MARIADB_EXPOSE_LOCAL %}-h127.0.0.1 -P3306{% endif %} -u root -p\"$${MARIADB_ROOT_PASSWORD}\" -e 'SHOW DATABASES;'"
+        - "healthcheck.sh --su-mysql --connect --innodb_initialized"
       interval: 10s
       timeout: 5s
       retries: 18