feat(cfold): canonicalize custom test layout

tests/custom-html/PARITY.md

@@ -1,13 +1,13 @@
 # Parity — custom-html
 
 Phase-2 P2 mapping table: every `references/recipe-maintainer/recipe-info/custom-html/tests/*.py` has
-a comparable cc-ci test under `tests/custom-html/functional/`, asserting the **same thing** (not just
+a comparable cc-ci test under `tests/custom-html/custom/`, asserting the **same thing** (not just
 a renamed file). The Adversary cold-verifies parity by reading the source `recipe-info/<file>` and the
 cc-ci file side-by-side.
 
 | recipe-maintainer file | cc-ci file | what's verified | status |
 |---|---|---|---|
-| `recipe-info/custom-html/tests/health_check.py` | `tests/custom-html/functional/test_health_check.py` | The app is reachable over HTTPS and returns a successful response (the original asserted HTTP 200 against a persistent instance). The cc-ci port preserves the assertion shape — non-5xx status — and adapts to the ephemeral per-run domain via the `live_app` fixture. | **ported** |
+| `recipe-info/custom-html/tests/health_check.py` | `tests/custom-html/custom/test_health_check.py` | The app is reachable over HTTPS and returns a successful response (the original asserted HTTP 200 against a persistent instance). The cc-ci port preserves the assertion shape — non-5xx status — and adapts to the ephemeral per-run domain via the `live_app` fixture. | **ported** |
 
 ## Recipe-specific tests (Phase-2 P3, ≥2 beyond parity)
 
@@ -17,8 +17,8 @@ content, fetch it back"). Two new functional tests beyond parity:
 
 | cc-ci file | what's verified | rationale |
 |---|---|---|
-| `tests/custom-html/functional/test_content_roundtrip.py` | Writes a uniquely-marked content file to the served volume via `lifecycle.exec_in_app` and asserts an HTTPS GET to the corresponding path returns that exact byte content — proves the app serves files written into its served volume, not a static synthetic page. | The recipe IS a content-server: a roundtrip is the canonical proof it works for what it's for. |
-| `tests/custom-html/functional/test_content_type_header.py` | Writes both an `.html` and a `.txt` marker to the served volume, fetches each, and asserts `Content-Type` reflects the file type (`text/html`, `text/plain`) — proves nginx is properly serving with MIME-typed responses, not just returning bytes. | Distinctive nginx-served behavior — distinguishes a working nginx from a misconfigured one that emits everything as `application/octet-stream`. |
+| `tests/custom-html/custom/test_content_roundtrip.py` | Writes a uniquely-marked content file to the served volume via `lifecycle.exec_in_app` and asserts an HTTPS GET to the corresponding path returns that exact byte content — proves the app serves files written into its served volume, not a static synthetic page. | The recipe IS a content-server: a roundtrip is the canonical proof it works for what it's for. |
+| `tests/custom-html/custom/test_content_type_header.py` | Writes both an `.html` and a `.txt` marker to the served volume, fetches each, and asserts `Content-Type` reflects the file type (`text/html`, `text/plain`) — proves nginx is properly serving with MIME-typed responses, not just returning bytes. | Distinctive nginx-served behavior — distinguishes a working nginx from a misconfigured one that emits everything as `application/octet-stream`. |
 
 Both tests run in the **custom** stage against the same `live_app` shared deployment as the
 lifecycle overlays — no extra deploy, no extra teardown.
@@ -32,7 +32,7 @@ via `lifecycle.exec_in_app` (volume-direct, immune to the post-backup serving ra
 
 ## Playwright (P6)
 
-`tests/custom-html/playwright/test_browser_smoke.py` covers the browser-rendered nginx HTML — already
+`tests/custom-html/custom/test_browser_smoke.py` covers the browser-rendered nginx HTML — already
 exercised inline by `tests/custom-html/test_install.py::test_serving_and_content` (lifecycle install
 overlay), which uses Playwright Chromium to confirm the page renders. The Phase-2 split file is the
 canonical home for browser-flow coverage and is invoked by the **custom** stage.

tests/custom-html/custom/test_browser_smoke.py

@@ -1,7 +1,7 @@
 """custom-html — Playwright UI flow (Phase 2 P6).
 
-The recipe-maintainer corpus did not ship a Playwright test for custom-html — but plan §4.1 names
-`playwright/` as the canonical home for browser flows where a recipe's core UX is a UI. custom-html
+The recipe-maintainer corpus did not ship a Playwright test for custom-html — but the cfold layout
+uses `custom/` as the canonical home for browser flows where a recipe's core UX is a UI. custom-html
 serves HTML; a browser-rendered fetch (vs raw HTTP) proves the page actually renders and any client-
 side resources resolve. Distinct from `tests/custom-html/test_install.py` which runs Playwright as
 part of the lifecycle INSTALL overlay; this file is the standalone Phase-2 custom-stage version, so a