fix(ci): treat an unreadable cache size as unstable when settling (#7274)

The settle loop initialised prev='' and, after 4795d04 made total() return
empty on failure, two consecutive failed `buildctl du` reads compared equal and
tripped the stability counter. The loop then exited after ~2s instead of its
120s bound — exactly when du is failing and the prune is most likely still
deleting, which is the case the wait exists to cover. Handing back early there
risks the builder post-step SIGKILLing buildkitd and skipping the sticky disk
commit.

An empty reading can only mean du failed. buildctl prints its `Total:` line
unconditionally (cmd/buildctl/diskusage.go), so an empty cache still reports
`Total: 0B` and settles normally. Guarding on a non-empty reading therefore
costs nothing in the healthy paths: verified a steady value and an empty cache
both still exit after 3 iterations, while a persistently failing du now waits
out all 60.

Reported by cubic on #7273.

Author: waleedlatif1

.github/actions/docker-build/action.yml

@@ -142,7 +142,14 @@ runs:
           prev=''; stable=0
           for _ in $(seq 1 60); do
             cur="$(total)"
-            if [ "$cur" = "$prev" ]; then
+            # An empty reading means du FAILED, never that the cache is empty:
+            # buildctl prints its `Total:` line unconditionally (cmd/buildctl
+            # diskusage.go), so an empty cache still reports `Total: 0B`. Without
+            # the -n guard the initial prev='' matched two empty readings and the
+            # loop exited after ~2s -- precisely when du is failing and the prune
+            # is most likely still deleting. Treat it as unstable and wait out the
+            # bound instead.
+            if [ -n "$cur" ] && [ "$cur" = "$prev" ]; then
               stable=$((stable + 1))
               [ "$stable" -ge 2 ] && break
             else