Release candidate 4 (app version 0.9.10): full restore over SFTP reads ahead; SFTP leg in the full-restore test

PLAN.md

@@ -386,9 +386,15 @@ in README "Known limitations":
 - **1.0.0 (besluit 2026-10-18):** alleen betrouwbaarheid. rc2 uitgebracht; slaagt de grote
   DR-test op VM 980 (snapshot van 12-10, met `--skip-missing-tables`), dan 1.0.0. Zo niet: fix,
   rc3, en rc3 pas uitbrengen na een geslaagde volledige DR-test.
+- **rc4 (besluit 2026-10-19):** rc3 is niet uitgebracht. De DR-test met rc3 liep ~2,8 MiB/s
+  (~3,5 dag); parallel lezen over SFTP haalde vanaf VM 980 ~7,6 MiB/s. Daarom rc4 = rc3 +
+  vooruitlezen over SFTP (4 eigen verbindingen). Volgorde: volledige DR-test op VM 980 volgens de
+  gids (SFTP, Storage Box) → rc4 uitbrengen en om tests vragen → zelf een volledige DR van een
+  productie-instantie van ~250 GB via S3 en via SMB. Drie volledige DR-restores vóór 1.0.0.
+  Problemen of meldingen van gebruikers: rc5.
 - **1.0.1:**
-  1. Herstelsnelheid: bij een restore meerdere pakketten tegelijk lezen (SFTP: meerdere
-     verbindingen; S3 heeft al 16 tegelijk). Raakt het leespad, daarom niet in 1.0.0.
+  1. (Naar rc4: herstelsnelheid over SFTP.) S3 leest al 16 tegelijk bij index en tree, maar een
+     restore leest de packs nog één voor één: ook vooruitlezen via de S3-client.
   2. Waarschuwing in de beheerpagina en `backup:status` als achtergrondjobs niet op systeem-cron
      staan, en "waiting for background jobs" als een lopende backup lang geen stap zette (issue
      #13). Cron zelf aanzetten kan de app niet: zonder echte cron-regel stopt dan alles.