feat(subscribe): queue Weeztix coupon, then Mailwizz; document queues

- RegisterSubscriberOnPage: persist subscriber then dispatch integrations
- IssueWeeztixCouponForSubscriber on weeztix queue; dispatches Mailwizz after
  coupon attempt (idempotent if coupon_code already set); failed() fallback
- SyncSubscriberToMailwizz implements ShouldQueueAfterCommit
- Deployment: worker listens weeztix,mailwizz,default; warn against sync in prod
- .env.example: QUEUE_CONNECTION notes for subscribe UX

Made-with: Cursor

documentation/DEPLOYMENT-STRATEGY.md

@@ -269,6 +269,11 @@ Laravel ships with a `public/.htaccess` that works with Apache. Verify `mod_rewr
 
 ### 4.7 Set up cron for queue worker + scheduler
 
+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).
+- **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:
 
 ```
@@ -276,9 +281,11 @@ In DirectAdmin → Cron Jobs, add:
 * * * * * cd /home/username/preregister && php artisan schedule:run >> /dev/null 2>&1
 
 # Queue worker - process one job per run (every minute)
-* * * * * cd /home/username/preregister && php artisan queue:work --once --queue=mailwizz >> /dev/null 2>&1
+* * * * * cd /home/username/preregister && php artisan queue:work --once --queue=weeztix,mailwizz,default >> /dev/null 2>&1
 ```
 
+For higher throughput, use a persistent supervisor-managed worker instead of `--once` in cron; keep the same `--queue=weeztix,mailwizz,default` order.
+
 ### 4.8 Directory permissions
 
 ```bash