docs: merge (1 lange afbeelding) = standaard leverroute; update README

AGENTS.md

@@ -188,15 +188,20 @@ getransmitteerd was) — ze zijn géén bezorgbewijs en gaven verkeerde signalen
   **`MEDIA_SEND_DELAY_MS`** (bridge-`.env`: `/home/aiaiaiaiagent/wwebjs-api/.env`, nu `500`
   sinds 2026-09-28 teruggezet van 1000; delay lost de race niet op, zie RCA)
   ná elke media-send.
-- **Bot-side pagina-pacing (`PAGE_SEND_DELAY_MS`, bot-`.env`, nu `3000`)**: sinds
+- **MERGE = de standaard leverroute sinds 2026-10-05 (`src/messageHandler.js`)**:
-  2026-10-05 wacht de bot ná elke pagina (behalve de laatste) voordat de volgende
+  een meerpagina-dienst wordt door de bot samengevoegd tot **EEN lange afbeelding**
-  gestuurd wordt. Reden: ook verse single-sends van een "verloren" blz komen aan, maar
+  (`magick … -append`, `MERGE_PAGES=true`, `MAGICK_BIN=/home/linuxbrew/.linuxbrew/bin/magick`
-  de paarsgewijze flow (blz 2 direct na blz 1, brug-delay 500 ms) verliest blz 2 steeds
+  in bot-`.env`) en als één enkele image gestuurd. Elimineert de staged-ghost
-  opnieuw (casus 4027: 3 botruns + herhaalde opvraag na re-render). De pauze maakt elke
+  (2e pagina van een paar verliest) deterministisch: enkele sends komen aan, gepaarde
-  pagina een effectief losse send — enige sends falen empirisch niet. `0` zet uit.
+  sends niet — bewezen (4027: pair verliest blz 2 al dagen; 1 lange afbeelding kwam wél
-  Waarde gemeten (2026-10-05): transmissie-latentie naar ontvanger-sessie ≈ 0.83 s
+  aan). Bij merge-falen (bv. magick ontbreekt) valt de bot terug op per-pagina-sends
-  (848/833/827 ms via zelf-send + sessie-Eddy-poll); 3000 = 0.83 × ~3.5 marge.
+  met `PAGE_SEND_DELAY_MS`. Enkele-pagina-diensten worden as-is gestuurd (geen merge).
-  De brug-delay zelf NIET verhogen (delay loss effect, RCA 26-09).
+  UX: één scrollbaar beeld i.p.v. twee losse; bewuste keuze boven `sendMediaAsDocument`
+  (document moet in extern programma geopend worden).
+- **Bot-side pagina-pacing (`PAGE_SEND_DELAY_MS`, bot-`.env`, `3000`)** is sindsdien
+  alleen nog een fallback (bij merge-falen). Gemeten transmissie-latentie naar
+  ontvanger-sessie ≈ 0.83 s (848/833/827 ms); 3000 = ×3.5 marge. De brug-delay zelf
+  NIET verhogen (delay loss effect, RCA 26-09).
 - **Bridge-`.env`-wijzigingen**: `env_file` wordt bij container-create gelezen → een
   `MEDIA_SEND_DELAY_MS`-wijziging werkt pas na een **recreate**
   (`cd ~/wwebjs-api && sudo -A docker compose up -d`); een kale `docker restart` (ook de

README.md

@@ -151,13 +151,14 @@ gaven verkeerde signalen. Enige betrouwbare bronnen: het apparaat en `getInfo`
 (`message.getInfo()` → `read`/`readRemaining`). De bridge-`delivery`/acs van de store zijn
 nooit leveringsbewijs.
 
-> **🛡️ Media-pacing zit bridge-breed (2026-09-26), niet in de bot.** Staged-ghost-race:
+> **🛡️ Eén lange afbeelding per dienst (2026-10-05) — de standaard.** Meerpagina-diensten
-> de wwebjs-media-pipeline is één tab; een direct-opvolgende media-send (van elke client)
+> worden door de bot samengevoegd tot **één enkele image** (`magick -append`,
-> overlapt en de 2e verliest (in store + ack2 maar nooit verzonden). De bridge serialiseert
+> `MERGE_PAGES=true`) en als één send verstuurd. Elimineert de staged-ghost (2e pagina van
-> nu alle media-sends over alle sessies en wacht `MEDIA_SEND_DELAY_MS` (bridge `.env`, 500;
+> een paar verliest): gepaarde media-sends overlappen en de 2e verliest (in store + ack2
-> wederzijds bevestigd dat delay de race niet oplost; teruggezet van 1000 op 2026-09-28)
+> maar nooit verzonden); één enkele send komt deterministisch aan — verificatie 2026-10-05
-> ertussen. De bot pauzeert niet. Details/config/locatie: zie AGENTS.md en vault "Whatsapp
+> (ook JPEG, delay en ack-gate losten het niet op). Bij merge-falen valt terug op
-> rest-api.md". Tijdelijke mitigatie; permanente fix (fork) staat open.
+> per-pagina-sends met `PAGE_SEND_DELAY_MS`. Keuze vóór `sendMediaAsDocument` (geen externe
+> opener nodig). Details/config: zie AGENTS.md en vault "Whatsapp rest-api.md".
 
 ## Spam protectie