Вынос health-check-service в отдельный сервис

Тикер офлайн-детекции (internal/healthcheck) переехал из
device-control-service в новый самостоятельный Go-сервис — как и
планировалось с самого начала (см. изначальный README-заглушку).
Детекция online остаётся в device-control-service: она происходит
как побочный эффект уже имеющейся там MQTT-подписки на
devices/+/telemetry и devices/+/ack, заводить для этого отдельный
сервис с дублирующей MQTT-подпиской избыточно.

health-check-service — свой Go-модуль (без зависимости от proto/,
сборка из собственного контекста), читает только узкое
read+offline-подмножество Device Shadow keyspace в Redis
(devices:known, status, last_seen) — полный Shadow API с записью
desired/reported state остаётся только в device-control-service.

Метрика device_control_health_transitions_total переименована в
device_health_transitions_total и теперь публикуется с этим именем
из ДВУХ сервисов (device-control-service — direction=online,
health-check-service — direction=offline): Prometheus агрегирует
одноимённые метрики с разных таргетов прозрачно, поэтому Grafana-
дашборд адаптирован простой сменой имени метрики в запросе, без
переделки панели.

Проверено вживую через docker compose: реальный online→offline
переход (публикация тестовой телеметрии + ожидание таймаута)
корректно долетает до Redis и RabbitMQ (device.status_changed),
Prometheus видит новый scrape-таргет как up.

services/health-check-service/README.md

@@ -1,12 +1,51 @@
 # health-check-service (Go)
 
-Статус: пока не реализован. Может начаться как горутина внутри
-device-control-service и позже выделиться в отдельный контейнер — поэтому
-с первого дня держим отдельную директорию, чтобы это разделение прошло
-безболезненно.
+Статус: реализован.
+
+Изначально жил как горутина-тикер внутри device-control-service (см. его
+README/git-историю) — выделен в отдельный сервис по мере роста проекта,
+как и планировалось с самого начала.
 
 Зона ответственности:
-- Периодически (по тикеру) проверяет `last_seen` каждого устройства в Redis.
-- Когда устройство превышает таймаут офлайна, переводит его `status` в
-  `offline` и публикует событие для notification-service.
-- Хороший повод продемонстрировать горутины + graceful shutdown в Go.
+- Периодически (по тикеру, `HEALTH_CHECK_INTERVAL`) обходит все известные
+  устройства из Redis-множества `devices:known` и проверяет `last_seen`
+  каждого.
+- Когда устройство превышает таймаут офлайна (`HEALTH_CHECK_TIMEOUT`),
+  переводит его `status` в `offline` в том же Redis (Device Shadow
+  keyspace, который device-control-service читает/пишет) и публикует
+  `device.status_changed` в RabbitMQ.
+
+Не входит в зону ответственности:
+- **Детекция перехода в online.** Это происходит как побочный эффект
+  MQTT-подписки device-control-service на `devices/+/telemetry` и
+  `devices/+/ack` (там уже есть открытое соединение и подписка ради
+  reported_state) — заводить для этого отдельный сервис с собственной
+  MQTT-подпиской избыточно. health-check-service работает только "в одну
+  сторону": online → offline.
+- Хранение/интерпретация телеметрии — это ingest-service.
+- Знание о существовании устройств из PostgreSQL — этот сервис, как и
+  device-control-service, не подключается к Postgres: список устройств для
+  сканирования берётся из того же Redis-множества `devices:known`
+  (пополняется device-control-service).
+
+## Метрики
+
+`GET /metrics` на `HEALTH_CHECK_METRICS_PORT`. Счётчик
+`device_health_transitions_total{direction="offline"}` — намеренно та же
+метрика (по имени), что device-control-service публикует для
+`direction="online"`: Prometheus агрегирует одноимённые метрики с разных
+таргетов прозрачно, так что дашборд Grafana не пришлось переделывать под
+разделение на два сервиса.
+
+## Запуск
+
+```bash
+cd services/health-check-service
+go test ./...
+go build ./cmd/health-check-service
+```
+
+Конфигурация — через переменные окружения (секция health-check-service в
+корневом `.env.example`). Не зависит от `proto/` — работает только с Redis
+и RabbitMQ, поэтому в отличие от device-control-service/rule-engine-service
+сборка Docker-образа идёт из собственного контекста (не корня репозитория).