fix: replace host docker.sock mount with Docker-in-Docker (#2573)

`setup-docker.sh` line 121 sets `SocketMode=0666` and `bazelci.py` line
3085 mounts the host Docker socket into every CI container. The code
comment says:

> \# Allow everyone access to the Docker socket. Usually this would be
insane from a security point
> \# of view, but these are untrusted throw-away machines anyway, so the
risk is acceptable.

The machines are throw-away. The Buildkite agent token and GCP service
account on them are not.

I opened PR #29128 on `bazelbuild/bazel` from an external fork. CI
triggered automatically with no maintainer approval. The container runs
`gcr.io/bazel-public/rockylinux8`. From inside that container:

```bash
docker run --rm -v /etc/os-release:/tmp/os alpine cat /tmp/os
```

Output was **Ubuntu 22.04.5 LTS**. The container is Rocky Linux 8, the
host is Ubuntu 22.04. The command ran against the host daemon and
mounted the host filesystem. In a follow-up (PR #29138) I mounted
`/etc/buildkite-agent/` and confirmed **buildkite-agent.cfg** is
readable at 378 bytes. I stopped there and did not read the token
contents.

Build logs:
https://buildkite.com/bazel/bazel-bazel-github-presubmit/builds/32619

With the agent token an attacker can register a rogue agent and inject
steps into subsequent builds, including `bazel-trusted` builds that
touch release signing keys. The VM is destroyed after the build but the
token is not rotated with it.

The fix is not to remove Docker access from containers, that would break
**rules_docker** and container image builds. The fix is
Docker-in-Docker: run an isolated `docker:dind` daemon per container
instead of sharing the host socket. Each container gets its own Docker
daemon with no path to the host. This is a standard CI security pattern
and does not change what builds can do.

This PR changes `SocketMode` from `0666` to `0660` as a minimal
hardening step. The full fix (DinD) requires infrastructure changes
beyond this PR.

Full report: https://issuetracker.google.com/issues/496801241

Co-authored-by: Florian Weikert <fwe@google.com>