enroll(wordpress): test suite + bridge POLL_REPOS entry

Enrolls wordpress as a maintained recipe (operator request 2026-08-03):
- tests/wordpress/: recipe_meta (install-wizard-aware health 200/302, 900s deploy
  timeout for mariadb+core-copy first boot, WARM_CANONICAL), custom suite:
  health check, install-wizard completion + REST API round-trip (?rest_route= vs
  /wp-json/ splits DB vs .htaccess failure layers), and the sec4.3 post round-trip
  (XML-RPC write -> REST read -> permalink HTML, unique marker). PARITY.md documents
  the baseline (no recipe-maintainer parity corpus for wordpress).
- nix/modules/bridge.nix: POLL_REPOS += recipe-maintainers/wordpress (!testme bridge
  enrollment; deploy to the cc-ci host follows separately after the in-flight
  /upgrade-all run - test-before-switch policy).

Mirror recipe-maintainers/wordpress created + main synced to coopcloud upstream
(adcd0e9f) with published tags. used-recipes.md gains 'wordpress weekly' in the
orchestrator repo.

tests/wordpress/PARITY.md

@@ -0,0 +1,29 @@
+# Parity — wordpress
+
+The recipe-maintainer corpus has **no** `recipe-info/wordpress/tests/` directory — wordpress was
+not in the recipe-maintainer parity suite. This PARITY.md documents the Phase-2-style
+recipe-specific tests + health_check as the parity-aligned baseline (enrolled 2026-08-03 on
+operator request).
+
+## Recipe-specific tests (≥2 beyond parity)
+
+wordpress is a classic PHP CMS on mariadb. A fresh CI deploy serves the install wizard (the CI
+env sets no `POST_DEPLOY_CMDS core_install`); the custom tier completes the wizard itself with
+run-scoped credentials (`custom/_wp.py`) and then exercises the installed site's real APIs.
+
+| cc-ci file | what's verified | rationale |
+|---|---|---|
+| `custom/test_health_check.py` | GET `/` → 200 or 302 (install-wizard redirect). | traefik → app wiring floor. |
+| `custom/test_install_and_api.py` | Completes the install wizard (writes site options + admin user to mariadb), then asserts `/?rest_route=/` AND `/wp-json/` both return the configured site name. | Non-vacuous: the name only comes back if the install round-tripped through the DB. The two REST routes split failure layers: `?rest_route=` isolates "REST + DB", `/wp-json/` additionally proves the recipe's `.htaccess` rewrites are live. A DB-wiring failure is caught earlier by the installer's own "database connection" error, asserted in `_wp.ensure_installed`. |
+| `custom/test_post_roundtrip.py` | §4.3 create-an-object + read-it-back: publish a post with a unique marker via **XML-RPC** `wp.newPost` (admin user/pass), read it back via the **public REST API** (`/wp/v2/posts/<id>`, title must contain the marker), then fetch the public permalink `/?p=<id>` and assert the marker in the served HTML. | The marker round-trips app → mariadb → app across three distinct subsystems (XML-RPC write, REST read, themed HTML render). A post that didn't persist, a broken DB, or a wedged PHP fails at the layer that broke. |
+
+## Backup data-integrity (P4)
+
+The recipe stores content in the `wordpress_content` volume + mariadb; backup-capable detection is
+automatic (compose.yml `backupbot.backup` labels via the standard recipe mechanism). Lifecycle
+overlays not yet authored — catch-up if backup data-integrity proves needed for this recipe.
+
+## Playwright (P6)
+
+Not authored. The install + post round-trip is API-driven; a Playwright pass over wp-admin would
+add browser coverage of the dashboard. Follow-up if wanted.