feat: media-send pacing na élke send (niet alleen tussen pagina's)

MEDIA_SEND_DELAY_MS pauzeert nu centraal in sendImageMessage ná elke
media-send, zodat ook afbeeldingen naar verschillende ontvangers niet
overlappen in de ene chromium-tab (staged-ghost race-risico). Per-pagina
delay uit messageHandler verwijderd.

README.md

@@ -145,6 +145,15 @@ Bij elke interactie met de groep controleert de bot of het pinned bericht nog be
 
 ## Ack-tracking (ghost-send detectie, sinds 2026-09-24)
 
+> **⚠️ 2026-09-26 — ack-tracking is voor media ongeldig gebleken.** Zie de RCA in
+> AGENTS.md ("staged-ghost = race-conditie"): de bridge resolvet media-sends optimistisch
+> op lokale staging en fabriceert daarna óók de live `message_ack`-events (bewijs: dienst
+> 5219 blz 2 kreeg `ack=2` voor een bericht dat nooit getransmitteerd was). Daardoor:
+> (1) de tracker stopt bij gefabriceerde ack ≥ 2 en mist de ghost; (2) "live ack" is géén
+> bezorgbewijs meer — enige waarheid is het apparaat en `getInfo` (`read` blijft leeg).
+> De klasse is een **race bij 2+ media achter elkaar** (altijd de 2e pagina), niet een
+> bestandprobleem; `MEDIA_SEND_DELAY_MS` en re-render (poppler) lossen het niet op.
+
 Sommige mediabestand-verzendingen keren `success` + message-ID terug maar worden nooit
 **bezorgd**: ze blijven op één grijs vinkje hangen (ack 1) en de ontvanger ziet niets
 aankomen. Dit is een bestand×ontvanger-interactie in WhatsApp's mediaverwerking (niet de
@@ -181,15 +190,17 @@ sessie — zie AGENTS.md). De bot detecteert dit via `message_ack`-events en waa
 | `ACK_STUCK_TIMEOUT_MS` | Leeftijd zonder ack 2 = stuck | `300000` (5 min) |
 | `ACK_PRUNED_AFTER_MS` | Stale tracking opruimen | `1800000` (30 min) |
 | `ACK_CHECK_INTERVAL_MS` | Checkinterval (alleen actief bij pending) | `30000` |
-| `MEDIA_SEND_DELAY_MS` | Pauze tussen pagina's van één dienst (niet vóór de eerste) — geeft de wwebjs media-pipeline lucht | `500` |
+| `MEDIA_SEND_DELAY_MS` | Wacht ná élke media-send (media-pipeline is één tab; voorkomt overlappende sends naar elk doel) | `1500` |
 
 Opvallende logregels: `[ack] track …`, `[ack] delivered ack=…`, `[ack] pruned …`.
 
 > **Let op — bridgestore is geen bezorgbewijs (2026-09-24):** de lokale store van wwebjs-api
 > (`/chat/fetchMessages`-acks) kan ack 1/2/3 tonen voor berichten die de ontvanger nooit zag
-> (ghost-sends). Trek hier géén leveringsconclusie uit. Ack-tracking gebruikt de **live
-> `message_ack`-progressie**, niet de store; bevestiging komt van het apparaat van de
-> ontvanger.
+> (ghost-sends). Trek hier géén leveringsconclusie uit. **En sinds 2026-09-26 geldt hetzelfde
+> voor de live `message_ack`-progressie** (zie waarschuwing bovenin deze sectie): ook die
+> kan gefabriceerd zijn bij een staged-ghost. Enig betrouwbaar bridgesignaal is `getInfo`
+> (`message.getInfo()` → `read`/`readRemaining`); eindoordeel is altijd het apparaat van
+> de ontvanger.
 
 ## Spam protectie