feat: Add presence heartbeat for Matrix online status

- matrix-gateway: POST /internal/matrix/presence/online endpoint
- usePresenceHeartbeat hook with activity tracking
- Auto away after 5 min inactivity
- Offline on page close/visibility change
- Integrated in MatrixChatRoom component

MONITOR-AGENT-STATUS-CHECK.md

@@ -0,0 +1,116 @@
+# ✅ Статус Monitor Agent - Перевірка
+
+## 📊 Поточна ситуація
+
+### 1. Запуск агентів на НОДА2
+
+**Чи реально запустити всіх агентів?**
+- ✅ **Так, реально!** Автоматичний деплой налаштовано
+- ✅ При завантаженні сторінки `/nodes/node-2` автоматично запускається деплой
+- ⚠️ **Але:** Потрібен реальний backend API endpoint для деплою
+
+**Як це працює:**
+1. При відкритті сторінки НОДА2 автоматично перевіряється статус
+2. Знаходяться не задеплоєні агенти
+3. Автоматично запускається деплой (через 3 секунди)
+4. Якщо API не доступний, використовується mock деплой
+
+**Що потрібно для реального деплою:**
+- Backend API endpoint: `POST /api/v1/node2/agents/{agentId}/deploy`
+- Або локальний endpoint: `POST /api/agent/{agentId}/deploy`
+- Або інтеграція з NodeAgent для реального деплою
+
+---
+
+### 2. Monitor Agent пам'ять
+
+**Чи запам'ятовує Monitor Agent всі зміни на порту 8899?**
+- ✅ **Так!** Автоматичне збереження налаштовано
+- ✅ WebSocket `/ws/events` збирає всі події
+- ✅ Події автоматично зберігаються в Memory Service (PostgreSQL)
+- ✅ Батчинг для оптимізації (10 подій або 5 секунд)
+
+**Як це працює:**
+1. WebSocket підключення до `/ws/events`
+2. Всі події автоматично додаються до батчу
+3. Батч зберігається в Memory Service через `/api/memory/monitor-events/batch`
+4. Події зберігаються з `agent_id = "monitor-{node_id}"`
+
+**Де зберігаються події:**
+- PostgreSQL: таблиця `agent_memory_events`
+- Agent ID: `monitor-node-2` (для НОДА2)
+- Scope: `long_term`
+- Kind: `node_event`, `agent_event`, `system_event`, `project_event`
+
+**Перевірка:**
+```bash
+# Перевірити збережені події
+curl http://localhost:8000/agents/monitor-node-2/memory?limit=10
+```
+
+---
+
+### 3. Monitor Agent чат
+
+**Чи може Monitor Agent відповідати на питання?**
+- ⚠️ **Частково:** Endpoint налаштовано, але потребує backend
+- ✅ Frontend готовий: `POST /api/agent/monitor/chat`
+- ⚠️ Backend endpoint: потребує DAGI Router або прямий LLM
+
+**Як це працює:**
+1. Frontend відправляє запит: `POST /api/agent/monitor/chat`
+2. Backend має обробити через DAGI Router або прямий LLM
+3. Monitor Agent має доступ до пам'яті через Memory Service
+4. Відповідь формується на основі пам'яті та системних даних
+
+**Що потрібно для повної роботи:**
+- Backend endpoint `/api/agent/monitor/chat` має:
+  - Отримувати повідомлення
+  - Запитувати пам'ять з Memory Service
+  - Формувати контекст з подій
+  - Відправляти до LLM (через DAGI Router або прямий)
+  - Повертати відповідь
+
+**Fallback:**
+- Якщо backend не доступний, показується помилка
+- Можна додати mock відповіді для тестування
+
+---
+
+## 🔧 Рекомендації
+
+### Для реального деплою агентів:
+1. Створити backend endpoint для деплою
+2. Інтегрувати з NodeAgent для реального запуску
+3. Або використати існуючий API для деплою агентів
+
+### Для Monitor Agent пам'яті:
+1. ✅ Вже працює автоматично
+2. Перевірити чи Memory Service запущений
+3. Перевірити чи WebSocket підключений
+
+### Для Monitor Agent чату:
+1. Створити backend endpoint `/api/agent/monitor/chat`
+2. Інтегрувати з Memory Service для отримання контексту
+3. Підключити до LLM (DAGI Router або прямий)
+
+---
+
+## ✅ Що вже працює
+
+- ✅ Автоматичний деплой агентів (з fallback)
+- ✅ Збереження подій в Memory Service
+- ✅ WebSocket підключення для подій
+- ✅ Батчинг для оптимізації
+- ✅ Frontend для чату з Monitor Agent
+
+## ⚠️ Що потребує backend
+
+- ⚠️ Реальний деплой агентів (потрібен API)
+- ⚠️ Monitor Agent чат (потрібен backend endpoint)
+- ⚠️ Інтеграція з LLM для відповідей
+
+---
+
+**Status:** ✅ Frontend готовий, ⚠️ Backend потребує реалізації
+