feat(campaign): bound synchronous delivery

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