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
 
@@ -20,7 +20,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - uses: https://git.aceofba.se/logaritmisk/setup-buildx@v1
+      - uses: https://git.aceofba.se/infra/setup-buildx@v1
 
       - uses: docker/build-push-action@v6
         with:
@@ -37,7 +37,6 @@ jobs:
 | Name | Default | Description |
 |------|---------|-------------|
 | `endpoint` | `tcp://buildkit.gitea.svc.cluster.local:1234` | BuildKit TCP endpoint. Override only if you run a private buildkit somewhere else. |
-| `install` | `false` | Set up `docker build` as alias to `docker buildx build`. |
 | `version` | `latest` | buildx version, passed through to the upstream action. |
 
 ## Why
@@ -49,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.