fix: isolate public subscribe from integration job failures

Queue Weeztix/Mailwizz after the HTTP response and catch dispatch errors.
Jobs log Mailwizz/Weeztix API failures without rethrowing so sync driver
and terminating callbacks do not surface 500s after a successful create.

Add JS fallback for non-JSON error responses, deployment note, and a
regression test for failing Mailwizz under QUEUE_CONNECTION=sync.

Made-with: Cursor

documentation/DEPLOYMENT-STRATEGY.md

@@ -271,7 +271,8 @@ Laravel ships with a `public/.htaccess` that works with Apache. Verify `mod_rewr
 
 Public registration saves the subscriber in the database first, then queues **Weeztix** (coupon code) and **Mailwizz** sync jobs. Those jobs must be processed by a worker.
 
-- **Production:** set `QUEUE_CONNECTION=database` (or `redis`) — never rely on `sync`, or a Mailwizz/Weeztix failure can return HTTP 5xx to the visitor while the subscriber is already stored (confusing UX).
+- **Visitor-facing behaviour:** the public subscribe endpoint returns **HTTP 200 with `success: true`** as soon as the subscriber row is stored. Failures in Mailwizz or Weeztix are **logged** (and visible via failed jobs when using a real queue); they do **not** change the JSON shown to the visitor. Use logs and admin resync to diagnose integration issues.
+- **Production:** set `QUEUE_CONNECTION=database` (or `redis`) so retries and `queue:failed` work as intended. `sync` is acceptable for small installs but runs integration work in-process; still, the visitor should not see 5xx from a broken Mailwizz/Weeztix API after subscribe.
 - **Queues:** coupon jobs use `weeztix`; Mailwizz uses `mailwizz`. The worker should listen to both (order below prioritises `weeztix` so coupon creation tends to run before sync when both are pending).
 
 In DirectAdmin → Cron Jobs, add: