bot: pauze tussen pagina-sends (PAGE_SEND_DELAY_MS) tegen staged-ghost-race

AGENTS.md

@@ -185,11 +185,25 @@ getransmitteerd was) — ze zijn géén bezorgbewijs en gaven verkeerde signalen
   chromium-tab en verliest de 2e (bestaat in store + ack2 maar wordt nooit verzonden).
   De bridge serialiseert nu álle media-sends over alle sessies/clients door één keten
   (`serializeMediaSend` in `wwebjs-api-build-p25/src/utils.js`) en wacht
-  **`MEDIA_SEND_DELAY_MS`** (bridge-`.env`: `/home/aiaiaiaiagent/wwebjs-api/.env`, nu `500`)
-  ná elke media-send. De bot zelf pauzeert **niet**. Config/code/waarom volledig
-  gedocumenteerd in vault [[Whatsapp rest-api]] ("Bridge-wide media-send throttle") en
-  [[Dienst media bezorgtest]] (RCA 2026-09-26). Tijdelijke mitigatie — permanente fix
-  (fork: send óf echt transmetteren óf zichtbaar falen) staat nog open.
+  **`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 `15000`)**: sinds
+  2026-10-05 wacht de bot ná elke pagina (behalve de laatste) voordat de volgende
+  gestuurd wordt. Reden: ook verse single-sends van een "verloren" blz komen aan, maar
+  de paarsgewijze flow (blz 2 direct na blz 1, brug-delay 500 ms) verliest blz 2 steeds
+  opnieuw (casus 4027: 3 botruns + herhaalde opvraag na re-render). De pauze maakt elke
+  pagina een effectief losse send — enige sends falen empirisch niet. `0` zet uit.
+  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
+  wekelijkse timer) herlaadt de `.env` **niet**. Recreate = sessie-herverbinding, alleen
+  met expliciete toestemming (hard verbod op container-restart staat in de vault).
+  Config/code/waarom volledig gedocumenteerd in vault [[Whatsapp rest-api]]
+  ("Bridge-wide media-send throttle") en [[Dienst media bezorgtest]] (RCA 2026-09-26).
+  Tijdelijke mitigatie — permanente fix (fork: send óf echt transmetteren óf zichtbaar
+  falen) staat nog open.
 
 **Ack-semantiek (wwebjs 1.34.7):** ack 1 = verstuurd naar server (één grijs vinkje), ack 2 = bezorgd op apparaat (twee vinkjes), ack 3 = geopend/gelezen. Let op: eerdere notities die "één grijs vinkje (ack 2)" noemden, zaten er dus naast. **Let op 2 (2026-09-26):** óók deze acks zijn geen leveringsbewijs — zie RCA hieronder.
 
@@ -230,11 +244,23 @@ multi-page sends vanzelf en is de race weg.
 direct-opvolgende media-send overlapt in de ene tab en de 2e verliest.
 Bestand bytes zijn nooit het probleem; **re-render (poppler) is een dwaalspoor en geen
 fix** — het maskeerde de race alleen (nieuwe poging = nieuwe race-rol). Mitigatie =
-bridge-breed throttle (`MEDIA_SEND_DELAY_MS`, 500) — zie hierboven. Bij vermoeden:
+bridge-breed throttle (`MEDIA_SEND_DELAY_MS`, 500 — delay loss effect, RCA 26-09; teruggezet
+van 1000 op 2026-09-28) — zie hierboven. Bij vermoeden:
 opnieuw versturen, apparaat als waarheid.
 
+**1b. Transparante (alpha) PNG — WEL een bestandsklasse (2026-09-28, casus 4039).**
+Dienst 4039 (2 blz): blz 79 kwam **nooit** aan — ongeacht volgorde (078 eerst/laatst),
+timing (500/1000 ms), UI-reset ertussen of vice versa; verschijnt in beide stores met
+server-locators maar rendert niet op het apparaat. Verse `pdftoppm`-render (ondoorzichtig
+sRGB, 147 KB i.p.v. 186 KB RGBA) kwam **wel** aan; na vervanging van `4039-079.png`
+kwamen beide blz van 4039 aan. Vermoedelijke oorzaak: de opgeslagen PNG's zijn RGBA met
+~90% volledig transparante pixels; WhatsApp's re-encode-pipeline (PNG→JPEG) is berucht
+onbetrouwbaar met transparante PNGS (o.a. wwebjs-issues #2695 (silent fail PNG send,
+multi-device), #3603 (transparante PNG blurred), #201772 (image-send hang); loss of alpha op transparante PNG's in officiële clients ([StackOverflow 37554514](https://stackoverflow.com/questions/37554514/transparent-png-images-in-whatsapp))).
+554 van de 555 opgeslagen PNG's zijn RGBA met (deels transparante) achtergrond → zelfde risico op andere diensten (mogelijk de echte oorzaak van de klasse-1 "staged ghosts": de bestand-inhoud i.p.v. timing). De bot stuurt sinds `07b511e` mimetype op basis van extensie; ondoorzichtig renderen bij de bron lost het op; documents via `sendMediaAsDocument` omzeilt de image-pipeline maar is afgewezen als productie-richting.
+
 **2. Ontvanger offline/weigert (ack-1-hang)** — bericht staat gequeued, apparaat pakt het
-niet op. Check eerst óf het apparaat online is, wacht af; persoonsgebonden.
+niet op. Check eerst óf het apparaat online is wacht af; persoonsgebonden.
 
 > **Detectie/verificatie:** de bridgestore en live acks zijn **geen** bezorgbewijs (bridge
 > fabriceert ze). Enige betrouwbare bronnen: het apparaat en `getInfo`