Вынос 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/device-control-service/README.md

@@ -15,10 +15,10 @@
 - Поддерживает паттерн Device Shadow в Redis: `desired_state` (чего хочет
   пользователь) против `reported_state` (что подтвердило устройство), плюс
   `status` и `last_seen`.
-- Ведёт health-check горутиной-тикером: переводит устройство в `offline`,
-  когда `last_seen` превышает таймаут, и публикует событие в RabbitMQ
-  (`device.status_changed`) для будущего notification-service — как при
-  уходе в офлайн, так и при возврате online.
+- Переводит устройство в `online` и публикует `device.status_changed` в
+  RabbitMQ при получении телеметрии/ack (см. «Архитектурные решения»).
+  Обратный переход, `offline` по таймауту `last_seen`, — зона
+  ответственности отдельного health-check-service (см. его README).
 
 Не входит в зону ответственности: решение о том, *когда* отправлять команду
 на основе показаний датчиков — это логика rule-engine-service. Этот сервис
@@ -54,7 +54,9 @@
 `GET /metrics` на том же порту, что и команды (`DEVICE_CONTROL_HTTP_PORT`)
 — не открывали отдельный порт ради этого. Счётчики/latency команд
 (TurnOn/TurnOff/SetLevel по action+outcome), MQTT-событий (telemetry/ack),
-переходов online/offline health-check.
+переходов в online (`device_health_transitions_total{direction="online"}`
+— та же метрика по имени, что публикует health-check-service для
+`direction="offline"`, см. его README).
 
 ## Запуск