feat(campaign): bound synchronous delivery

docs/CAMPAIGN_DELIVERY_RUNBOOK.md

@@ -5,10 +5,12 @@ been validated, built, reviewed, and locked.
 
 ## Operating Modes
 
-- Local direct send: `CELERY_ENABLED=false`. Queueing stores jobs in the DB, and
-  small development runs can be processed with "Send queued now".
+- Local direct send: `CELERY_ENABLED=false`. **Send now** is available only for
+  exact built runs within the effective synchronous limit. It preflights the
+  complete batch before the first SMTP effect.
 - Worker send: `CELERY_ENABLED=true` with Redis/Celery workers running. Queueing
-  publishes delivery tasks, and the Review & Send page polls summary counters.
+  publishes durable delivery tasks, and Review and send polls their persisted
+  summary counters even after the initiating request has returned.
 - Mock send: use only for development review. It does not prove real SMTP/IMAP
   credentials or server policy.
 
@@ -26,6 +28,8 @@ been validated, built, reviewed, and locked.
   ZIP before using production recipients.
 - Keep the report page open during tests; it is the operational source of truth
   for attempts, outcomes, and reconciliation.
+- Confirm the effective Send now recipient-job limit. The safe default is 25;
+  use Queue for workers for ordinary batches or any run above that limit.
 
 ## Deliverability Preflight
 
@@ -49,10 +53,15 @@ Before the first live send for a sender domain or mail-server profile:
 1. Validate the version with file checks enabled.
 2. Build the version and inspect all blocking review items.
 3. Queue only after the selected version is the intended immutable execution
-   version.
-4. In local mode, use "Send queued now" for small test runs.
+   version. Select **Queue for workers**, then verify the committed and
+   published counts.
+4. Use **Send now** only if the exact eligible count is non-zero and at or below
+   the effective deployment/tenant limit shown on the page.
 5. In worker mode, verify queue counters move from queued/claimed/sending to a
    terminal SMTP state.
+6. If a synchronous request is used, keep Review and send open: it polls the
+   durable counters while the request runs. A rejection occurs before SMTP and
+   directs oversized runs to workers.
 
 ## Outcome Handling
 

docs/CAMPAIGN_HANDBOOK.md

@@ -156,11 +156,13 @@ operator sequence.
 
 At a minimum:
 
-1. Queue only a validated, locked, built version. The current Web UI does not
-   expose Queue; use an authorized supporting client or API.
-2. Use worker delivery for ordinary batches. Synchronous Send now has no
-   server-enforced job-count bound and must be used only after an operator has
-   deliberately confirmed a small controlled run.
+1. Queue only a validated, locked, built version. Use **Queue for workers** for
+   ordinary batches; the durable progress remains visible after leaving and
+   returning to Review and send.
+2. Use **Send now** only when the exact persisted eligible build is within the
+   effective synchronous limit shown by the UI. The default deployment limit
+   is 25 recipient jobs. The backend repeats the count and preflights every
+   message and the Mail profile revision before contacting SMTP.
 3. Treat `smtp_accepted` as protected from ordinary retry.
 4. Retry `failed_temporary` explicitly after inspecting the cause.
 5. Include `failed_permanent` only after correcting the cause and making a
@@ -179,6 +181,14 @@ Pause stops new eligible work but cannot undo a provider effect already in
 progress. Cancel marks work that has not yet produced a protected SMTP outcome;
 it cannot recall accepted mail.
 
+The deployment ceiling is configured with
+`GOVOPLAN_CAMPAIGN_SYNCHRONOUS_SEND_MAX_RECIPIENTS` (0 disables Send now; the
+accepted range is 0–500). A tenant may only narrow that ceiling with
+`tenant.settings.campaign_delivery_policy.synchronous_send_max_recipients`.
+The effective value and source are returned by the protected delivery-options
+API, recorded for successful/rejected synchronous commands, and stated in the
+configured handbook topic.
+
 ### Test and one-message actions
 
 The current baseline includes mock send, queue dry-run, synchronous immediate