chore: settle product naming across app, widget and deployments

One word everywhere: ReplyPier in UI copy, package and image names, the
replypier.site domains (app/api/docs/help), REPLYPIER_* settings and the
--rp-* design tokens.

- public widget API is window.ReplyPier with replypierId / replypierBaseUrl /
  replypierConfig / replypierToken, loader at webclient/replypier.min.js;
  both bundles rebuilt from source
- NOTICE, llms.txt, CONTRIBUTING, HELP_CENTER_INFRA and the demo runtime
  config rewritten; the demo config ships no third-party keys
- migration adds the ReplyPier managed model value to the AI model enum
- local compose project, database, role, volume and Docker network carry the
  same name

replypier-test/README.md

@@ -0,0 +1,69 @@
+# ReplyPier Widget Test
+
+This is a test project for the ReplyPier chat widget integration.
+
+## UI options gallery
+
+`ui-options.html` has one card per widget placement/behaviour (floating left/right,
+custom size and offsets, sidebar drawers, search-bar trigger, hidden launcher + own
+button, custom z-index, dashboard defaults, page-overrides-beat-dashboard, mobile).
+Each opens `ui-test.html` with that configuration plus buttons for the whole JS API
+(`open/close/toggle/isOpen`, `open({message})`, `hide/showLauncher`, `setPosition`,
+`data-replypier-open`, `trigger` selector) and an event log.
+
+Use it in **Stub** mode (fake widget, no backend needed) or **Real** mode (set your
+widget ID + API URL on the gallery page). The Loader URL setting controls where
+`replypier.min.js` comes from — the frontend dev server by default.
+
+## Setup
+
+1. Install dependencies:
+
+```bash
+npm install
+```
+
+2. Start the test server:
+
+```bash
+npm start
+```
+
+3. Open http://localhost:3000 in your browser
+
+## Testing the Widget
+
+1. Make sure the ReplyPier frontend development server is running (usually at http://localhost:5173)
+2. Click the "Initialize Widget" button on the test page
+3. Use the chat widget that appears in the bottom-right corner
+
+## Development Notes
+
+- The widget script is loaded from the local development server
+- The test page uses a dummy widget ID ('test-widget-123')
+- CORS is enabled to allow loading the widget script from a different origin
+
+## Where things are served from
+
+- **Loader** (`replypier.min.js`) — the **frontend** (`http://localhost:5173/webclient/…`),
+  the same origin the dashboard's embed snippet points at. The backend does **not**
+  serve it, and no copy is kept in this folder: a copy goes stale and you end up
+  testing an old widget while the source looks correct.
+  It is a build artifact — after editing `frontend/src/webclient/replypier.js` run
+  `cd ../frontend && npm run build:webclient:prod`.
+- **Widget app** (`widget.js`) — the backend, from `backend/assets/`. Rebuild with
+  `cd ../frontend && npm run build:widget:prod` after changing `WidgetBuilder.vue`
+  or the widget composables.
+- **API** — set `window.replypierBaseUrl`. Without it the loader falls back to the URL
+  baked in at build time, which for a production build is the cloud API, so a "local"
+  test silently talks to api.replypier.site.
+
+## Troubleshooting
+
+- **"Chat can't load on 'localhost'"** — the origin isn't in your organization's allowed
+  domains (Organization settings). The port matters: `localhost:3000` allowed does not
+  permit `localhost:3010`.
+- **Dashboard placement settings not applying** — almost always a stale loader. Check the
+  served file has the newer features: `curl -s <loader-url> | grep -c sidebar-left`.
+- **Buttons do nothing on the gallery pages** — the loader failed to load; the page shows
+  a red banner saying so.