Make the site test's resource names unique per run, not per PID

The Gitea site test has been red since 03b0e13, and the cause was not the disk:

  Error response from daemon: network with name wpci-147-net already exists

id was "wpci-$$". A Gitea job runs in a fresh container where the shell gets a
low PID, and those REPEAT across runs — so the name collides with the leftovers
of any earlier run that did not clean up, and every subsequent run landing on
the same PID is wedged permanently. The same script never collides on a laptop,
where PIDs are large and varied, which is why this was invisible outside the
runner.

That also corrects something this repo believed: "the containers are already
safe (wpci-<pid>)" was written about concurrent sessions on one machine, where
it is true. It does not hold across container boundaries, where the PID space
restarts.

Two changes. The name now carries the epoch and $RANDOM, so it is unique per
run even in a container that always starts at the same PID. And because the
name is now unique to this run, anything already using it is debris from a
crashed run and is ours to clear, so the containers and network are removed
before they are created — without that, one wedged name stays wedged forever,
which is what happened here.

Proven both ways: staging a stale wpci-147-net reproduces the exact daemon
error under the old scheme, and the new pre-remove creates cleanly over it.

Two consecutive real site tests then ran green, leaving zero wpci-* networks
and zero wpci-* containers, with no leak warning from the check added in the
previous commit.

Worth recording how that was measured. A global `docker volume ls | wc -l`
around one of those runs showed a delta of 2 — none of it this run's. Several
sessions share this box and run these container pairs concurrently, so a
neighbour's volumes read as your leak. The attributed check inside cleanup(),
which asks the containers what they own, reported nothing and was right.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ci/site-test.sh

@@ -25,8 +25,23 @@ WP_VERSION="${WP_VERSION:-latest}"
 WC_VERSION="${WC_VERSION:-latest}"
 PHP_VERSION="${PHP_VERSION:-8.3}"
 
-id="wpci-$$"
+# 🔴 NOT just $$. A Gitea job runs in a fresh container where the shell gets a
+# low PID, and those REPEAT across runs — so "wpci-$$" collides with the
+# leftovers of any earlier run that did not clean up, and the job dies on
+# `network with name wpci-147-net already exists`. Measured on Gitea run 999:
+# every run landing on PID 147 was wedged permanently, while the same script on
+# a laptop never collides because PIDs there are large and varied.
+#
+# The epoch and $RANDOM make the name unique per run even inside a container
+# that always starts at the same PID.
+id="wpci-$$-$(date +%s)-${RANDOM:-0}"
 net="$id-net"
+
+# The name is unique to this run, so anything already using it is debris from a
+# crashed run and is ours to clear. Without this a single wedged name stays
+# wedged forever, which is exactly what happened on the Gitea runner.
+docker rm -f -v "$id-db" "$id-cli" >/dev/null 2>&1 || true
+docker network rm "$net" >/dev/null 2>&1 || true
 # 🔴 -v, and it is the whole bug. `mariadb:lts` declares VOLUME
 # /var/lib/mysql, so every run creates an ANONYMOUS volume, and `docker rm -f`
 # does not remove anonymous volumes — only `docker rm -f -v` does. The named