docs: move trusted CI runner from NAS to Server

docs/BUILDING.md

@@ -29,6 +29,17 @@ resources and are not runtime mounts or dependencies.
 
 ### CI with a host Docker socket
 
+The managed CI runner runs on Ubuntu Server; the NAS no longer executes jobs.
+It retains `ubuntu-latest` compatibility and fixed runner/job image digests,
+accepts one job at a time, and limits each task container to 4 CPUs and 8 GiB.
+The runner's private state resides on the guarded business disk. Its systemd
+service checks the mount identity before starting. Registration credentials are
+supplied through a temporary file and removed after registration; the daemon
+container does not retain the reusable registration token in its environment.
+Keep the current runner and job images even when no task is executing: they are
+active CI dependencies. Only trusted repository events may reach this runner's
+Docker socket; CI does not automatically deploy production or write to frames.
+
 Run `python scripts/ci-compose-verify.py` after loading the build mirror profile.
 The script derives a temporary Compose document from production settings, with
 an absolute client-side build context, a UUID project name, a unique CI image
@@ -40,7 +51,7 @@ owned `/data` and `/config` directories; the service remains UID/GID 10333.
 
 Build contexts are sent by the Docker client, so the job workspace can remain
 inside the job container. Runtime storage is managed by the daemon; no matching
-NAS host `/workspace` directory is needed. HTTP readiness and the unmodified
+Docker host `/workspace` directory is needed. HTTP readiness and the unmodified
 nine-endpoint smoke script run inside the service with `compose exec -T`.
 Restart is followed by another readiness check and the same smoke test.