build: imaget hentes fra vores egen Gitea, og runen peger derind

GitHub er utilgængeligt i ti dage. Koden ligger allerede begge steder; det, der
manglede, var imaget og et sted at bygge det.

**Imaget ligger i Gitea nu**, begge arkitekturer. Kopieret med
`docker buildx imagetools create`, som flytter hele manifest-indekset mellem to
registre uden at hente lagene ned — en `docker pull` på denne maskine ville have
hentet arm64 og efterladt serveren uden en amd64 at køre.

**Og det kan hentes uden legitimation, mens repoet bliver ved med at være
privat.** Det var ikke givet: panelets `PullImage` sætter aldrig `RegistryAuth`,
så et privat register er udelukket, og Gitea gør normalt en container-pakke privat
sammen med det repo, den hører til. Men en pakke bindes kun til et repo, når den
skubbes med et repo-link — og denne er ikke, så dens synlighed følger brugeren
`kw`, som er offentlig.

Bevist frem for antaget: `docker --config /tmp/tom pull` hentede den med samme
digest som GHCR havde. En bar `curl` mod `/v2/…/manifests/…` svarer 401 også for
et læsbart image, fordi registret uddeler et anonymt token først — så den er ikke
prøven, og den kostede en runde at gennemskue.

**Runen er bumpet til version 5.** Ikke fordi felterne ændrede sig, men fordi en
rune ikke opdaterer sig selv: panelet skriver rune-rækken fra en UI-handling, så
ændringen kræver **Runes → verdande → Update**, og katalog-listen caches ti
minutter.

**Et Actions-workflow til Gitea** ligger i `.gitea/workflows/`. Sin egen fil frem
for en delt: `secrets.GITHUB_TOKEN` findes ikke der, registret er et andet, og der
er ingen Releases-side at skrive til. En delt fil ville være fire betingede led,
der hver kun gælder ét af de to steder. Den laver ingen release, fordi
opdateringsnotitsen i appen læser GitHubs — skal den flyttes med, er det
`internal/update`, der skal have en ny adresse.

**Det virker ikke endnu:** der er ingen runner registreret på Gitea. Indtil der er,
bygges og skubbes imaget i hånden herfra.

Dokumentationen og landingssiden siger den nye adresse. Rune-siden er skrevet om,
hvor den fortalte om GHCR-pakkeindstillinger, og siger nu, hvordan man prøver
efter på den måde, der faktisk svarer på spørgsmålet.

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

rune/verdande.yaml

@@ -15,14 +15,30 @@ gameskill:
   # this: a manifest with new fields and an unchanged version is a manifest the
   # panel has no reason to re-read, so the fields never appear and the failure is
   # silent — the server's settings page simply does not offer them.
-  version: 4
+  # Bumpet til 5, fordi imagets adresse flyttede. En rune opdaterer ikke sig selv:
+  # panelet skriver rune-rækken fra en UI-handling, så ændringen her kræver
+  # **Runes → verdande → Update** — og katalog-listen caches ti minutter, så to
+  # forsøg lige efter hinanden kan begge give den gamle version.
+  version: 5
   icon: "app"
 
   # The image is distroless — no shell — so keep_entrypoint runs the binary the
   # image already declares as its ENTRYPOINT, and startup.exec passes it argv
   # directly rather than through /bin/sh, which does not exist in there.
+  # Hentes fra vores egen Gitea frem for fra GHCR.
+  #
+  # Panelets `PullImage` sætter aldrig `RegistryAuth`, så registret skal kunne
+  # læses anonymt. Det kan det her: pakken er *ikke* knyttet til repoet — Gitea
+  # binder kun en container-pakke til et repo, når den bliver skubbet med et
+  # repo-link — så dens synlighed følger brugeren `kw`, som er offentlig, mens
+  # `kw/verdande` bliver ved med at være privat. Bevist med en `docker pull` uden
+  # nogen legitimation, som hentede samme digest som GHCR havde.
+  #
+  # Skubbes den nogensinde på en måde, der knytter den til repoet, bliver den
+  # privat med det samme, og panelet får `No such image` — lydløst, fordi
+  # `pullImageRetry` kasserer fejlen og `ContainerCreate` først slår op lokalt.
   docker:
-    image: "ghcr.io/kristianwind/verdande:latest"
+    image: "gitea.nolimit.dk/kw/verdande:latest"
     data_path: /data
     keep_entrypoint: true