Rebrand: Co-op Check-in -> Co-op Survey in user-facing copy

Updates the tool product name across the app UI (header, page title,
section labels, form buttons, success/error states, report stat labels),
README, deployment docs, and the CiviCRM email template guidance.
Custom domain references move from check-in.fci.coop to survey.fci.coop
(DNS update still required).

The underlying CiviCRM "Check-in (organizing)" activity type, custom
group machine names (Check_in_data__organizing_), health-check ids,
and the internal org_engagement_check_in form id are unchanged --
those are CiviCRM contract surfaces, not product copy.

README.md

@@ -1,4 +1,4 @@
-# Co-op Check-in
+# Co-op Survey
 
 A tokenized, mobile-friendly web form that lets external co-op contacts
 update their organization's tracking data on CiviCRM, plus a read-only
@@ -11,8 +11,8 @@ Each co-op has a designated **Primary Contact** (the individual) linked
 to the **Organization** record in CiviCRM. Staff send that contact a
 personalized link generated against the contact's CiviCRM checksum:
 
-- `https://check-in.fci.coop/?cid=<contactId>&cs=<checksum>` — the form
-- `https://check-in.fci.coop/report?cid=<contactId>&cs=<checksum>` — the report
+- `https://survey.fci.coop/?cid=<contactId>&cs=<checksum>` — the form
+- `https://survey.fci.coop/report?cid=<contactId>&cs=<checksum>` — the report
 
 When the link is opened, the app verifies the checksum against CiviCRM,
 resolves the organization through the Primary Contact relationship, and
@@ -24,12 +24,12 @@ Build → Fulfill & Stabilize). The org's current stage controls which
 sections are editable; past and current stages are open for editing,
 future stages render as previews with their fields locked so the co-op
 can see the framework ahead. Fields prefill with each value's most
-recent non-empty entry from past check-ins. On submit, a new
+recent non-empty entry from past surveys. On submit, a new
 "Check-in (organizing)" activity is created; nothing is overwritten.
 
 **Stage authority.** The current stage is derived from the most recent
 "Check-in (organizing)" activity whose Stage field is set. Staff own
-stage transitions by manually setting Stage on a check-in activity they
+stage transitions by manually setting Stage on a "Check-in (organizing)" activity they
 create; the form itself never writes Stage, so org self-submissions
 can't override a staff transition. Orgs with no stage-bearing activity
 default to "Inquiry."