fix(deploy): redirect DOCKER_CONFIG out of $HOME so ProtectHome doesn't kill builds

The api unit's ProtectHome=read-only made the user's HOME read-only
inside the unit's namespace. docker compose --build then tried to
write ~/.docker/buildx/activity/* and got EROFS — which we'd been
misdiagnosing as a buildx wedge for the last few iterations.

Real fix: set DOCKER_CONFIG and BUILDX_CONFIG in the unit's
Environment= to a path inside ReadWritePaths. Hardening stays on,
docker CLI writes to install_dir/.docker instead of /home/<user>/.docker.

The wedge classifier now detects this case (count==0 + /home/ in
the stderr path) and emits a recipe pointing at the env-var fix
instead of the driver-rebuild path. Test added.

Wiki gets the new branch first since it's the most common cause
on systemd-managed installs.

deploy/decnet-api.service.j2

@@ -14,6 +14,13 @@ SupplementaryGroups=docker
 WorkingDirectory={{ install_dir }}
 EnvironmentFile=-{{ install_dir }}/.env.local
 Environment=DECNET_SYSTEM_LOGS=/var/log/decnet/decnet.api.log
+# ProtectHome=read-only (below) makes the user's $HOME read-only inside
+# the unit's namespace, which breaks `docker compose build` because the
+# CLI writes ~/.docker/buildx/activity/. Redirect the docker CLI's
+# config root into install_dir (already in ReadWritePaths) so the
+# hardening stays on without crippling the build path.
+Environment=DOCKER_CONFIG={{ install_dir }}/.docker
+Environment=BUILDX_CONFIG={{ install_dir }}/.docker/buildx
 ExecStart={{ venv_dir }}/bin/decnet api
 StandardOutput=append:/var/log/decnet/decnet.api.log
 StandardError=append:/var/log/decnet/decnet.api.log