feat(deploy): enable Docker-in-Docker by default

[zaytcevcom]

Summary

The bot's quality gate runs entirely through Docker: Taskfile.yml sets DEV_TOOLS: docker run --rm ... dev-tools and every lint/test/vet/build target shells through it. In deploys the bot container ships the docker CLI but no daemon, so task ci/lint/tests fail with "cannot connect to the Docker daemon". The privileged dind sidecar path already existed in the repo but was gated off by enable_dind: false. This turns it on by default (an isolated daemon — not the host socket), fixes the startup race, and adds buildx to the image.

Changes per acceptance criterion

• AC1 — dind on by default: enable_dind: true in roles/claude_tg_bot/defaults/main.yml and the example inventory; the comment documents the opt-out for hosts that cannot run a privileged container.
• AC2 — startup-race fix: the dind service gains a healthcheck (docker info readiness probe) and the bot gains depends_on: { dind: { condition: service_healthy } }, both inside the {% if enable_dind %} guards in the deploy template. The local docker-compose.yml gets the same healthcheck but no bot depends_on (there dind is behind profiles: ["dind"], so a hard dependency would force/break a normal docker compose up).
• AC3 — buildx: docker-buildx-plugin appended to the existing docker apt install line in adapters/telegram/Dockerfile and adapters/vk/Dockerfile (no new apt source; removes the "legacy builder deprecated" warning, enables BuildKit).
• AC4 — docs: both .env.example files and README.md note that deploys enable dind by default and the playbook injects DOCKER_HOST automatically.

How it was verified

The Docker-based task gate cannot run in the build environment (no daemon — the very thing this fixes; it is a host gate). Static verification performed:

• Rendered docker-compose.yml.j2 for enable_dind true and false and validated each with docker compose config: true → dind service + healthcheck + bot depends_on: service_healthy + dind_storage volume; false → none of them (opt-out renders clean).
• Local docker-compose.yml validated in default and --profile dind modes: bot has no depends_on, profiles: ["dind"] intact, healthcheck present.
• Zero Go files touched.

Pre-PR review

One critic round on the local diff → APPROVE, risk low (clean round, zero blockers/majors). Confirmed: guards correct on both branches, docker info is a valid readiness probe for docker:27-dind with sane timings (10s/5s/5/30s), no host-socket exposure or isolation drop.

Residual risks — needs a human eyeball

• Not run live: dind actually coming up healthy and the bot waiting correctly is a host/deploy check that could not run here. Confirm once on a real deploy that dind goes healthy within ~80s and the bot connects to tcp://dind:2375.
• Host reboot: depends_on: service_healthy is honored by compose up, not by the engine's restart policy after a reboot — the bot may start before dind is healthy again; relies on app-level retry to DOCKER_HOST.
• Fail-closed: on a host where dind cannot become healthy (privileged blocked, storage/kernel), the bot will not start — by design; such hosts must set enable_dind: false.
• Stale translations: the 7 localized READMEs still describe dind as an optional --profile dind sidecar (out of this PR's scope; sync in a follow-up if desired).