docs(launch): website-integration env vars + cutover sequence

deployment-plan.md gains a full env-var reference (CRM + website) and the cutover env-flip sequence; launch-readiness.md gets the 2026-06-02 closeout; BACKLOG.md adds the deferred integration-health-panel idea (section L).

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

docs/BACKLOG.md

@@ -435,3 +435,17 @@ not surfaced in §C above were resolved via the `fix(audit): …` commits
 - [`berth-recommender-and-pdf-plan.md`](./berth-recommender-and-pdf-plan.md) — berth recommender + per-berth PDF plan (Phases 0–8 shipped)
 - [`documenso-integration-audit.md`](./documenso-integration-audit.md) — Documenso integration spec (drives §A)
 - [`website-refactor.md`](./website-refactor.md) — public website cutover plan
+
+---
+
+## L. Website "integration health" panel (post-launch idea)
+
+**Raised 2026-06-02 (Matt); verdict: NOT worth building pre-launch.**
+
+A CRM admin "control panel" to watch website log events / activity. Reasons to defer:
+
+- Inquiry visibility already exists: `website_submissions` + its triage inbox (open / assigned / converted / dismissed).
+- Website traffic/events are already covered by Umami; app + error logs belong in pino/server logs (or a log tool), not a hand-rolled CRM page. Shipping website logs into the CRM is net-new bidirectional plumbing plus a security surface for marginal gain.
+- Not launch-blocking; classic pre-launch scope creep.
+
+**If revisited post-launch:** scope it to ONE small "integration health" card on the admin dashboard — last website submission received, count today, intake 4xx/5xx rate, inquiry email-send success. Pure read, no new ingestion pipeline. Build only if a real operational need surfaces; during cutover this is observable via logs + the submissions inbox.