docs: reflect runner-embedded cache and persistent buildkit

The standalone gha-cache-server was removed; cache traffic now lands in
the act-runner's embedded Actions API (persisted on a 50Gi PVC). BuildKit
itself also moved to a 100Gi Longhorn PVC.

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

README.md

@@ -6,8 +6,8 @@ cluster.
 
 Use this whenever a Gitea Actions workflow needs to build images. It removes
 the boilerplate of declaring a remote driver every time, and ensures every
-build reuses the cluster's BuildKit + the GitHub Actions cache server
-(`gha-cache-server`) for layer caching.
+build reuses the cluster's BuildKit instance (persistent 100 GiB Longhorn
+PVC + tuned GC) for layer caching across runs.
 
 ## Usage
 
@@ -48,6 +48,9 @@ cluster does run a standalone BuildKit Service (`buildkit-service` Helm
 chart, port 1234) which buildx can talk to via its `remote` driver. This
 action wires that in by default.
 
-The per-job runner pod already exports `ACTIONS_CACHE_URL` /
-`ACTIONS_RUNTIME_TOKEN` pointing at `gha-cache-server`, so `cache-from`/
-`cache-to: type=gha` works without any extra config.
+`cache-from`/`cache-to: type=gha` also works out of the box: the act-runner
+image (christopherhx/gitea-actions-runner) ships its own embedded Actions
+Cache / Results API and injects `ACTIONS_CACHE_URL` / `ACTIONS_RUNTIME_TOKEN`
+into the job container. That cache is persisted on the runner's `/data` PVC,
+so it survives pod restarts. There is no separate cache-server deployment to
+configure.