overlay policy: standardize the ccci overlay filename to compose.ccci.yml

Operator: use a single uniform filename `compose.ccci.yml` per recipe (one file
holding all cc-ci-side deploy tweaks) rather than per-purpose suffixes like
compose.ccci-health.yml. Updated §9 + plan-ccci-compose-overlay-policy.md; added
a DoD item to rename tests/{ghost,discourse}/compose.ccci-health.yml ->
compose.ccci.yml and update their install_steps.sh cp target + recipe_meta
COMPOSE_FILE.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

cc-ci-plan/plan.md

@@ -834,8 +834,10 @@ Each default stands until the Adversary or reality forces a change; record the c
   cc-ci-authored compose overlay (an extra `compose.*.yml` layered via `COMPOSE_FILE`) risks **drift**
   from the recipe users actually run, so **avoid it where possible and justify each use**. In most
   cases the cleaner fix is an **upstream recipe PR** — either a genuine robustness fix, or exposing a
-  knob the recipe should expose. **But a uniform, optional `compose.ccci-*.yml` overlay file per
+  knob the recipe should expose. **But a single, uniform, optional `compose.ccci.yml` overlay file per
   recipe is an acceptable fallback** — especially for a value abra/compose can't take from an env var.
+  (One fixed filename per recipe — `compose.ccci.yml` — holding all cc-ci-side deploy tweaks; not
+  per-purpose suffixes.)
   **Known limitation (builder, 2026-05-30): abra does NOT support an env value for a healthcheck
   `start_period`.** So the ghost/discourse `start_period` bumps legitimately **need** the overlay (an
   env-var PR is not possible for that field) — these overlays **stay**, justified. When you do use an