tests: add libredesk (LibreDesk helpdesk) recipe test suite

New recipe recipe-maintainers/Libre-Desk (abra TYPE=libredesk): app libredesk
v2.4.0 on :9000 + postgres:17 + redis:7. Adds:
- recipe_meta.py: /health probe, BACKUP_CAPABLE (backupbot db labels), upgrade
  EXPECTED_NA (only one published version so far), WARM_CANONICAL.
- install_steps.sh: insert format-compliant enc_key (32-hex) + admin_pwd
  (upper+lower+num+special) before deploy — abra's generic generator doesn't
  satisfy LibreDesk's strict secret formats.
- custom/: /health 200 probe + served-shell brand/asset probe (real app, not a
  fallback 200).

tests/libredesk/recipe_meta.py

@@ -0,0 +1,32 @@
+# Per-recipe harness config for libredesk (LibreDesk — open-source, self-hosted customer-support /
+# help desk; recipe repo recipe-maintainers/Libre-Desk, abra TYPE=libredesk).
+#
+# Stack (compose.yml): app (libredesk/libredesk:v2.4.0, serves on :9000 behind Traefik) + db
+# (postgres:17-alpine, user/db=libredesk) + redis (redis:7-alpine). abra-entrypoint.sh self-installs
+# the schema and runs migrations on boot (`--install --idempotent-install` then `--upgrade`), so the
+# stack comes up ready with no post-deploy step.
+#
+# Secrets have STRICT formats that abra's generic generator does not satisfy, so install_steps.sh
+# inserts compliant values before the single deploy (see that file):
+#   - enc_key   must be 32 hex chars (AES-256 key)         → openssl rand -hex 16
+#   - admin_pwd must be 10–72 chars, upper+lower+num+sym   → the "System" user's password
+#   - db_password is abra-generated (no special format) and left as-is.
+
+HEALTH_PATH = "/health"        # the app's own healthcheck endpoint (compose hits :9000/health)
+HEALTH_OK = (200,)
+DEPLOY_TIMEOUT = 600           # app + postgres + redis; app runs install+migrate on first boot
+HTTP_TIMEOUT = 300
+BACKUP_CAPABLE = True          # db carries backupbot.backup labels (pg_dump pre-hook / psql restore-hook)
+
+# Only one published version exists so far (0.1.0+v2.4.0), so there is no PRIOR deployable base to
+# upgrade FROM — the upgrade rung is intentionally N/A (a declared skip, never promoted to a pass).
+# Drop this once a second version is published; the dynamic base then resolves it (last-green warm
+# canonical → same-version step-back → main tip).
+EXPECTED_NA = {
+    "upgrade": "only one published version so far (0.1.0+v2.4.0) — no prior deployable base to "
+    "upgrade FROM yet; drop this when a second version ships",
+}
+
+# canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
+# The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.
+WARM_CANONICAL = True