umbreld pullt buiten compose om, dus pull_policy kon nooit werken

De installatie faalde, en de foutmelding was voorspelbaar maar de oorzaak niet:

  pull access denied for whatsnext/evolu-relay
      at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17

Die stacktrace is het punt. De pull komt uit docker-modem, de Docker-client van
umbreld zelf, dus rechtstreeks op de Docker Engine API. Compose komt er niet aan
te pas en de compose wordt alleen gelezen om te zien welke images erin staan.
pull_policy is een sleutel van de Compose-specificatie en wordt dus nooit
bekeken. Mijn reparatie van de vorige commit kon per definitie niet werken; hij
is eruit, want een sleutel die niets doet met een commentaar dat beweert van wel
is erger dan geen sleutel.

Waar die fout vandaan kwam: ik las in app-script dat install een
`compose "${app}" pull` doet en nam aan dat dat het pad was. Dat bestand is de
legacy-compat-laag en niet wat umbrelOS 1.x loopt bij een installatie vanuit de
interface. Dat staat nu als waarschuwing in de naslag, want het is precies het
soort bron dat overtuigend leest en het verkeerde antwoord geeft.

De echte regel, nu op het apparaat vastgesteld in plaats van uit code afgeleid:
elke image in de compose van een app moet anoniem uit een register te halen zijn.
Een lokaal gebouwde tag werkt niet, hoe goed docker compose up er ook mee overweg
zou kunnen.

Het image-veld staat er nog en wijst nog steeds naar de lokale tag. Dat is
bewust: het commentaar erboven zegt nu dat het zo niet werkt en wat er moet
komen. Weghalen zou de app-map stiller maar niet beter maken, en de keuze voor
een register is aan de gebruiker.

Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.

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

Docs/Referenties/Umbrel-appstore-spec.md

@@ -225,20 +225,40 @@ Alles daarbuiten wordt bij een update **niet** ververst. Een gewijzigde `entrypo
 `web/index.html` bereikt een bestaande installatie dus nooit; de gebruiker ziet zijn oude versie en er is
 geen foutmelding. Alleen een verwijdering en herinstallatie brengt het over.
 
-### Wat `app-script` met de images doet, en waarom dat een lokale tag breekt
+### Elke image moet uit een register komen, en `pull_policy` helpt niet
 
-Nagetrokken op 25-08-2026 in hetzelfde `app-script`, toen Evolu Relay een image kreeg die alleen lokaal
-bestaat. Twee regels daaruit bepalen wat er met een image gebeurt:
+**Op het apparaat vastgesteld op 25-08-2026**, bij de eerste installatiepoging van Evolu Relay met een
+image die alleen lokaal gebouwd was. De installatie faalde met:
 
-- **bij `install`, bij `update` en bij `post-patch-update` draait `compose "${app}" pull`.** Een tag die
-  niet in een register staat, laat de installatie dus falen vóórdat er iets gestart is. De uitweg is
-  `pull_policy: never` op die service: dan slaat compose hem over bij het ophalen en gebruikt wat er
-  lokaal staat. Dat is precies wat `whatsnext-evolu-relay` doet, en de reden staat er in commentaar bij;
-- **starten gaat met `compose "${app}" up --detach --build`.** Dat `--build` is het vermelden waard, want
-  het betekent dat umbreld een `build:`-blok in een compose wél zou uitvoeren. Toch is bouwen-in-de-app
-  hier geen goed idee: een `Dockerfile` staat niet in de update-whitelist hierboven, dus een nieuwe versie
-  vraagt een deïnstallatie, en de installatie hangt tijdens het bouwen. Het recept hoort daarom in
-  `tools/` in de repo en het resultaat in de Docker-opslag of in een register.
+```
+Error: (HTTP code 404) unexpected - pull access denied for whatsnext/evolu-relay,
+repository does not exist or may require 'docker login'
+    at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17
+```
+
+**Het beslissende detail is die stacktrace, niet de foutmelding.** De pull komt uit `docker-modem`, de
+Docker-clientbibliotheek van umbreld zelf, en dus rechtstreeks van de Docker Engine API. Compose komt er
+niet aan te pas. Dat is ook te zien aan de regels `Downloaded 40.5% of app` in de journal: umbreld haalt
+de images op en rapporteert de voortgang zelf.
+
+Twee gevolgen, en het tweede is een valkuil die een halve middag kost:
+
+1. **Elke `image:` in de compose van een app moet anoniem uit een register te halen zijn.** Een tag die
+   alleen in de lokale Docker-opslag van het apparaat staat, werkt niet, ook al zou `docker compose up`
+   hem daar prima vinden. De installatie stopt vóór het starten.
+2. **`pull_policy: never` verandert daar niets aan**, want dat is een sleutel van de Compose-specificatie
+   en umbreld leest de compose niet om te pullen; het leest alleen welke images erin staan. Dit is hier
+   geprobeerd en het faalde identiek.
+
+Wat hier eerder stond, en waarom dat misleidde: in `app-script` staat `compose "${app}" pull` bij
+`install`, `update` en `post-patch-update`, en `up --detach --build` bij het starten. Dat bestand is de
+**legacy-compat**-laag; op umbrelOS 1.x is het niet het pad dat een installatie vanuit de interface loopt.
+Lees dus niet uit `app-script` af wat umbreld doet zonder te controleren of die weg ook echt bewandeld
+wordt.
+
+Dat `--build` blijft trouwens ook zonder dit verhaal een slecht idee voor een app: een `Dockerfile` staat
+niet in de update-whitelist hierboven, dus een nieuwe versie vraagt een deïnstallatie, en de installatie
+hangt tijdens het bouwen. Een bouwrecept hoort in `tools/` in de repo, en het resultaat in een register.
 
 **Gevolg voor het ontwerp.** Zet logica die je later nog wilt kunnen wijzigen op een van deze plekken: