ci: age-filter the image prune so digest-pulled images survive

Run #17 showed `docker image prune -f` deleting the trivy image, which buys
back a 157MB pull on every subsequent run. An image pulled by digest carries no
tag, so it is dangling the moment its container exits, and bare dangling-only
pruning is not as narrow as it reads.

The act runner image survived the same prune only by accident: this step runs
inside an act container, so that image happens to be in use exactly while the
prune executes. That is luck, not design, and it would not hold if the step
ever moved.

An until=168h filter on both prunes keeps a week of recently used layers,
matching the buildx cache window already in place.

Verified in run #17 before this change: trivy logged "Need to update DB" zero
times, so the named-volume DB cache works, and registry digests equal the
chart's for all three images.

.gitea/workflows/ci.yaml

@@ -455,9 +455,16 @@ jobs:
         # week — recent enough that `--cache-from` still hits on normal traffic.
         #
         # Named volumes are never pruned here: that is where the trivy vuln DB lives.
+        #
+        # Both prunes carry an age filter, because "dangling" catches more than it looks.
+        # An image pulled by digest has no tag, so it is dangling the moment its container
+        # exits. A bare `docker image prune -f` therefore deleted the trivy image on every
+        # run and bought back a 157MB pull on the next one. The act runner image survived
+        # that only by accident: this step executes inside an act container, so the image
+        # is in use exactly while the prune runs. Relying on that is not a design.
         if: always()
         run: |
-          docker image prune -f
+          docker image prune -f --filter until=168h
           docker buildx prune -af --filter until=168h
           echo "--- dind disk after prune ---"
           docker system df