ci: buduj tylko zmienione usługi i sprzątaj po sobie na runnerze

Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do
mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała
nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się
wyłącznie tagiem.

Render i silnik B miały filtry ścieżek od początku (build-render.yaml,
build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana
przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego
commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`,
więc porównanie ścieżek jest dokładne, a nie przybliżone.

Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają
sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`,
a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania
(pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za
dużo niż wypuścić obraz ze starym kodem pod nowym tagiem.

SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać
między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być —
image-updater śledzi każdy obraz osobno i przypina to, co istnieje.

ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście,
nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na
problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy
liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje
budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej —
podstawiony katalog nowej usługi kończy przebieg kodem 1.

SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` —
bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg
zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy
renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe
i cache przeżywają i build nie zaczyna od zera.

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

.gitea/workflows/build-render.yaml

@@ -32,3 +32,14 @@ jobs:
           docker push $IMG:$TAG
           docker push $IMG:latest
           echo "Zbudowano i wypchnieto: $IMG:$TAG (+ latest)"
+
+      # Sprzątanie ZAWSZE, także po nieudanym budowaniu. Ten obraz dźwiga TeX Live
+      # i to właśnie na nim runner zatkał się kiedyś na „no space left on device" —
+      # a po nieudanym buildzie zostaje najwięcej śmieci.
+      - name: Sprzątanie po budowaniu
+        if: always()
+        run: |
+          docker system df || true
+          docker system  prune -af --filter "until=168h" || true
+          docker builder prune -f  --filter "until=168h" || true
+          docker system df || true