revert: verwijder ackTracker (dwaalspoor) — bridge fabriceert acks

ackTracker + message_ack-verwerking + check-loop + ACK_* env + docs uit de bot.
De bridge fabriceert acks (5219 blz 2 kreeg ack=2 zonder transmissie), dus
ack-tracking gaf verkeerde signalen. Enige betrouwbare bron: apparaat + getInfo.
Media-pacing zit nu bridge-breed (MEDIA_SEND_DELAY_MS). Poppler re-render als
fix verwijderd uit docs (wassen neus voor de race-klasse).

README.md

@@ -121,7 +121,6 @@ src/
   dailyStats.js         # Dagelijkse aanvraag-teller
   dienstService.js      # JSON lookup en PNG bestandspaden
   whatsappApi.js        # WhatsApp API client (bericht + afbeelding)
-  ackTracker.js         # Ack-tracking: hangende media detecteren
   telegramBot.js        # Telegram watchdog (apart process, health checks)
 ```
 
@@ -143,53 +142,14 @@ Bij elke interactie met de groep controleert de bot of het pinned bericht nog be
 - **Restart-loop preventie**: systemd `Restart=always` met `RestartSec=5`
 - **Webhook fout**: wordt gelogd in de logs
 
-## Ack-tracking (ghost-send detectie, sinds 2026-09-24)
+## Media-levering: acks & pacing (RCA 2026-09-26)
 
-> **⚠️ 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
-sessie — zie AGENTS.md). De bot detecteert dit via `message_ack`-events en waarschuwt.
-
-### Hoe het werkt
-
-1. **Vereiste:** wwebjs-api .env — `message_ack` uit `DISABLED_CALLBACKS` halen
-   (staat er sinds 2026-09-24 niet meer in) + container herstarten.
-2. `sendImageMessage` registreert elke verzending (`src/ackTracker.js`) met message-ID,
-   chat en bestandsnaam; de webhook (`message_ack` in `messageHandler.js`) update de ack.
-3. Bij **ack ≥ 2** (bezorgd op apparaat) wordt de tracking verwijderd.
-4. Blijft een bericht **> `ACK_STUCK_TIMEOUT_MS` (5 min) op ack < 2** → éénmalige
-   admin-notificatie (WhatsApp → Telegram-fallback) met bestandsnaam + chat en het advies
-   "opnieuw renderen + bezorgtest". Er volgt **geen sessie-herstart** (die helpt niet bij
-   een ack-1-hang) en geen resend naar de aanvrager.
-5. **Pruning:** entries worden na `ACK_PRUNED_AFTER_MS` (30 min) opgeruimd; de check-loop
-   is **activity-driven** (loopt alleen zolang er tracking open staat, geen 30s-polling
-   in rust).
-
-### Ack-semantiek (wwebjs 1.34.7)
-
-| ack | Betekenis |
-|-----|-----------|
-| 0 | onbekend/nete verstuurd |
-| 1 | verstuurd naar server (één grijs vinkje) — **hangt hier** |
-| 2 | bezorgd op apparaat (twee vinkjes) |
-| 3 | geopend/gelezen (blauwe vinkjes) |
-
-### Configuratie
-
-| Variabele | Doel | Default |
-|-----------|------|---------|
-| `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` |
+**Ack-tracking is VERWIJDERD (dwaalspoor).** De ack-tracker (`message_ack` → admin-melding
+bij ack<2) is uit de bot gehaald: de bridge fabriceert acks (dienst 5219 blz 2 kreeg
+`ack=2` voor een bericht dat nooit getransmitteerd was) — ze zijn geen bezorgbewijs en
+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:
 > de wwebjs-media-pipeline is één tab; een direct-opvolgende media-send (van elke client)
@@ -198,16 +158,6 @@ sessie — zie AGENTS.md). De bot detecteert dit via `message_ack`-events en waa
 > ertussen. De bot pauzeert niet. Details/config/locatie: zie AGENTS.md en vault "Whatsapp
 > rest-api.md". Tijdelijke mitigatie; permanente fix (fork) staat open.
 
-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. **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
 
 Elke gebruiker kan maximaal `MAX_REQUESTS_PER_DAY` (standaard 5) diensten per dag opvragen. Bij overschrijding krijgt de gebruiker een melding. De teller wordt dagelijks automatisch gereset (bij de eerste request na middernacht).