chore(brand): rename the product to ReplyPier

The upstream project name is gone from code, assets, docs and build
output: brand strings, domains (replypier.site and its app/api/docs/help
subdomains), env prefixes, image and network names, the widget's public
JS API (window.ReplyPier, replypierId/BaseUrl/Config/Token), CSS tokens
(--rp-*), file and directory names, and the WordPress plugin package.

- widget loader is now webclient/replypier.min.js; both bundles rebuilt
  from source (backend/assets/widget.{js,css}, frontend/public/webclient)
- NOTICE, llms.txt, CONTRIBUTING, HELP_CENTER_INFRA and config.dev.js
  rewritten rather than string-swapped; the demo config no longer ships
  the previous vendor's Firebase/Razorpay/Google keys
- new migration replypier_ai_model_001 adds REPLYPIER to the managed
  AIModelType and rewrites pre-rename rows
- local compose project, database, role and volume renamed; LOCAL_DEPLOY
  documents carrying the old local data over

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.