Testclient: gedeelde afhankelijkheden, en zicht op de WebSocket

Een fout van ons, gevonden door de gebruiker bij de tweede eigenaar: "Expected
tab leader port.". createEvoluDeps vraagt via navigator.locks het slot "tab" aan
en kondigt de houder aan als tab leader, en dat slot kan er maar een hebben.
openStore maakte per eigenaar een eigen stel afhankelijkheden, dus de tweede
werd nooit leider. Nu een stel per proces met een teller, zodat het pas
opgeruimd wordt als de laatste store sluit. Dit stond al als valstrik 2 in
PLAN.md 4e en was er alsnog in geslopen; de toets met twee eigenaars tegelijk
brengt hem terug zodra iemand dit ongedaan maakt.

Twee dingen erbij om te kunnen zien wat er met de relay gebeurt:

- spiegel <naam> opent dezelfde eigenaar in een lege database naast de
  bestaande. Alles wat daar binnenkomt heeft de heen- en terugreis over de relay
  gemaakt, en dat is de enige manier waarop de clientkant kan bewijzen dat er
  werkelijk iets op de relay staat; lees toont je altijd je eigen rijen.
- onWebSocket meldt welke URL geopend wordt en wat ermee gebeurt. Zonder dat
  ziet een relay die de socket dichtgooit er hetzelfde uit als een trage relay.

Dat luikje gaf meteen het antwoord: de socket komt nooit open, 1006, in een
herhaallus, en met het ws-pakket ernaast staat er wat de globale WebSocket
verzwijgt: 401. Twee eigenaars die eerder allebei 101 gaven zijn dus uit de
allowlist van de relay verdwenen. Dat is een vraag over de server-app en staat
als open punt 9, met vier verklaringen en wat ze uit elkaar houdt.

Suite: 478 goed, 0 fout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Docs/Plannen/Actief/003-Testclient/OPEN.md

@@ -46,7 +46,34 @@
    Voor de proeven is `klop` het antwoord, maar op de pagina staat een groen bolletje dat meer belooft dan
    het weet. Evolu heeft een `SyncState`; uitzoeken of daar iets bruikbaars in zit.
 
-9. **Het afsluiten is opgelost maar niet doorgrond.** De volgorde in `dispose` (afhankelijkheden, dan een
+9. **Twee toegelaten eigenaars zijn uit de allowlist van de relay verdwenen (09-09-2026), en we weten
+    niet waarom.** Ze gaven allebei 101 en even later allebei 401, met "turned away" op de statuspagina.
+    Dit is een vraag over de **server-app**, niet over de cliënt, en het is de eerste keer dat dit
+    gereedschap iets over de relay aan het licht brengt. Vier verklaringen, in volgorde van
+    waarschijnlijkheid:
+
+    1. **de relay is herstart voordat de allowlist weggeschreven was.** `isOwnerAllowed` zet alleen
+       `dirty`; het wegschrijven gebeurt in de lus. Een herstart in dat gat kost de net geleerde eigenaars.
+       `restart: on-failure` staat in de compose, dus een herstart hoeft niet opgemerkt te zijn;
+    2. **`owners.json` is als onleesbaar terzijde geschoven.** Daar heeft de relay een eigen logregel voor
+       ("owners.json was unreadable and has been moved aside"). Minder waarschijnlijk, want `writeState`
+       schrijft via een tijdelijk bestand en een hernoeming, dus een halve schrijfactie hoort niet te
+       kunnen;
+    3. **de blob van 2 MB heeft de relay laten struikelen.** Die zat boven `RELAY_MAX_WRITE_BYTES` en werd
+       vlak voor het verdwijnen geschreven. Als dat een herstart gaf, is dit verklaring 1 met een oorzaak;
+    4. de leerstand liet ze toe zonder ze te bewaren, en dan is er iets mis in `store.js`.
+
+    **Wat het uit elkaar houdt zijn de logregels van de relay-container**, en die kan alleen de gebruiker
+    lezen: `learned a new owner`, `owners.json was unreadable`, `refused a write of N bytes`, plus of de
+    container herstart is. Die laatste regel is bovendien de proef over de bytegrens, die van de
+    cliëntkant onzichtbaar is.
+
+10. **De bytegrens is van de cliëntkant niet te zien.** Een blob van 2 MB schrijven levert geen enkele
+    melding op: de cliënt is local-first, dus de rij staat er lokaal hoe dan ook, en de relay meldt een
+    geweigerde schrijfactie alleen in zijn eigen log. `spiegel` kan het indirect aantonen (de blob komt
+    dan niet terug), maar alleen als de synchronisatie verder werkt.
+
+11. **Het afsluiten is opgelost maar niet doorgrond.** De volgorde in `dispose` (afhankelijkheden, dan een
    tik doorlaten, dan de resources van de gedeelde worker, dan de runs) is gevonden door te proberen, niet
    door de bron van Evolu te lezen. Hij werkt en er is een reden bij opgeschreven, maar het is geen bewijs.
    Valt het bij een volgende versie opnieuw om, lees dan eerst `Task.js` in plaats van opnieuw te schuiven.