Het relay-programma: de relay van Evolu met onze eigen allowlist

tools/evolu-relay/src/ bevat nu een eigen programma dat createRelay uit
@evolu/nodejs aanroept met de twee terugroepfuncties die het bedoelde
uitbreidpunt vormen. De relay zelf komt uit npm en wordt niet nagebouwd of
aangepast; de opstartvolgorde is overgenomen uit apps/relay/src/index.ts van
Evolu zelf.

De opzet is drie bestanden met een harde scheiding, en die scheiding is de reden
dat hier iets te testen valt. policy.js bevat het beleid als pure functies: geen
bestanden, geen netwerk, geen klok. store.js is de enige plek met schijf erin.
index.js doet niets anders dan lezen, doorgeven en opslaan.

Het beleid: de eerste eigenaar die zich meldt wordt geleerd, een schakelaar
bepaalt of er nog nieuwe bij mogen, en een eigenaar is te blokkeren, alsnog toe
te laten of te vergeten. Geweigerde pogingen worden onthouden voor de pagina,
afgekapt op twintig, want elke poging is een id dat de ander zelf verzint. Een
onleesbaar owners.json wordt opzij geschoven en de app gaat dan dicht in plaats
van open: we weten dan niet wie er toegelaten was, en met de leerstand aan zou de
eerstvolgende die verbindt de nieuwe eigenaar worden.

Met test: node tests/test_limiter.mjs, 60 toetsen, en de toetsen gaan over de
guards en niet over het gelukkige pad. De beslissende regel is muteertest gedaan
en de juiste toets viel om: een geblokkeerde eigenaar mag er niet alsnog in
doordat de leerstand aanstaat. Het bestand is .mjs omdat de repo-root geen
package.json heeft en een .js daar als CommonJS gelezen zou worden.

build.sh bouwt niet langer de repo van Trezor maar onze eigen Dockerfile, dus git
is er niet meer voor nodig en de pin zit nu in package.json. De image is
node:24-slim en niet alpine, want better-sqlite3 heeft binaries voor glibc en niet
voor musl. Er is nog geen package-lock.json; het script waarschuwt daarvoor en het
staat als taak.

Onderweg bleek een aanname van vanmiddag fout: de 1 MB uit de gepubliceerde image
geldt per schrijfactie en niet per eigenaar. Er valt dus geen labelgeschiedenis
tegenaan te lopen. Dat is rechtgezet in het plan en in de naslag, en het getal is
overgenomen als bewuste keuze met RELAY_MAX_WRITE_BYTES ernaast.

Wat er niet in zit en ook niet gegokt is: data per eigenaar wissen. Het beleid kan
een eigenaar vergeten, maar zijn berichten staan in de SQLite van de relay, en dat
is andermans schema.

Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout).

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

Docs/Referenties/Upstream-evolu-relay.md

@@ -329,11 +329,13 @@ haken hetzelfde kan zonder die machinerie.
 `apps/relay/src/index.ts` staat `isOwnerAllowed` **uitgecommentarieerd** (dus iedereen mag erin) en
 `isOwnerWithinQuota` op **1 MB per eigenaar**. Dat is geen theorie maar de image die wij draaien:
 
-- **een kale relay is niet volledig ongelimiteerd.** Er zit een bovengrens op wat één eigenaar kan
-  wegschrijven, en dat dempt misbruik als gratis opslag meer dan gedacht;
-- **maar 1 MB is ook een plafond voor de échte gebruiker.** Loopt de labelgeschiedenis daar tegenaan, dan
-  stopt het synchroniseren, en dat merk je pas als het gebeurt. Wie zelf een relay bouwt, kiest dat getal
-  dus bewust.
+- **die grens geldt per schrijfactie en niet per eigenaar.** De relay geeft door hoeveel bytes déze actie
+  nodig heeft; er wordt niets opgeteld. Trezor telt wél op, maar dat doen ze zelf uit hun eigen tabel, en
+  die tabel is precies wat een kale relay niet heeft. Een labelgeschiedenis kan hier dus niet tegenaan
+  lopen;
+- **wat het wél tegenhoudt is één grote schrijfactie.** Dat dempt misbruik als gratis opslag, maar het is
+  geen totaalquotum. Wie dat wil, moet in de opslag van de relay kijken hoeveel een eigenaar al gebruikt,
+  en dat is schrijven noch lezen in je eigen schema.
 
 De relay zet zijn data in een map `data` naast het programma (`mkdirSync` plus `process.chdir`), en dat is
 het volume `/app/data` uit de image. In de database zitten onder meer `evolu_message` en `evolu_history`, en