## Текущая задача: отладка merkle sync в chatgui

### Контекст

Две инстанции chatgui обмениваются мемберами (участниками) каналов через merkle sync.
Одна на Linux (node `41eab6811e3ff67b`), вторая на Windows (node `32a3a1ee5625ceb9`).

### Что уже исправлено (vetka topo_upd)

1. **`conn_mgr.c:276`** — убрано требование `links_up` при поиске существующего коннекта.
   Раньше второй `conn_mgr_connect_node` (для второй группы/канала) не находил первый коннект
   потому что тот был в handshake (links_up=0) и создавал дублирующий линк → два init-таймера
   → два потока INIT-пакетов → бесконечный цикл реинициализации ETCP.

2. **`etcp_connections.c:insert_link_queue`** — детект коллизии адреса: если адрес уже занят
   ДРУГИМ коннектом → жирная ошибка + return -1 (вместо молчаливой замены).

3. **`etcp.c:etcp_conn_set_peer_node_id`** — детект коллизии peer_id: если key уже занят
   другим коннектом → жирная ошибка + return (не переиндексировать).

4. **`merkle_sync.c`** — исправлен формат сообщений:
   - Отправитель клал type ПЕРЕД ch_len+ns: `[svc][TYPE][ch_len][ns]...`
   - Получатель (`_recv_cb`) ожидал `[svc][ch_len][ns][TYPE]...` (как у chat_sync)
   - Переставлены байты в `_send_hashes`, `_send_batch`, MSG_REQUEST builder
   - Результат: handle_hashes/handle_request/handle_batch начали реально получать сообщения

5. **`merkle_sync.c`** — `_handle_batch` теперь вызывает `_session_done(s, MT_OK)` после
   обработки всех терминальных бакетов. До этого сессия никогда не завершалась,
   таймер истекал → retry → к тому моменту соединение уже отваливалось.

### Текущее состояние

Merkle sync обменивается сообщениями и завершает сессии (`session SYNCED` в логах).
Но данные мемберов не совпадают: Linux имеет 3 мембера в канале, Windows — 2.

### Найденная проблема (исследуется)

В логах `handle_batch` показывает `len=7` для обоих каналов с обеих сторон.
Это означает что в BATCH-сообщении данные мемберов = всего 2 байта (count=0).

При этом `merkle_tree_hash` показывает НЕнулевой bitmap (00008000) → `update_bucket_hash`
находит мемберов в бакете. Но `get_items` для того же бакета возвращает 0 записей.

**Гипотеза:** `update_bucket_hash` и `get_items` используют разную логику фильтрации
для одного и того же level/prefix → SQL запрос в `get_items` не находит мемберов.

Файлы: `tools/chatgui/transport/member_sync.c` функции `_member_update_bucket_hash` и `_member_get_items`.

### Данные из БД (Linux)

Канал 17611191138590969914: 3 мембера
- 4749809422690154107 (0x41eab6811e3ff67b — Linux self)
- 3648938168119840441 (0x32a3a1ee5625ceb9 — Windows peer) 
- 5749221071098079620 (0x4fc9561a7dfde984 — третий узел)

Канал 10175004475814804132: 2 мембера
- 3648938168119840441 (0x32a3a1ee5625ceb9)
- 4749809422690154107 (0x41eab6811e3ff67b)

Merkle tree для канала 176111...:
```
level=1 prefix=0x4000000000000000 member_count=1 hash=F612B771...
level=2 prefix=0x41E0000000000000 member_count=1 hash=F612B771...
level=3 prefix=0x41EA000000000000 member_count=1 hash=F612B771...
level=4 prefix=0x41EAB00000000000 member_count=1 hash=F612B771...
level=5 prefix=0x41EAB68000000000 member_count=1 hash=F612B771...
```

### Логи

Linux: `/home/vnc1/proj/utun3/tools/chatgui/build/chatgui.log`
Windows: `/home/vnc1/proj/utun3/tools/chatgui/build/chatgui2.log`

Конфиг: `db_sync=debug` включён.

### БД

Linux: `/home/vnc1/proj/utun3/tools/chatgui/build/chat_data/chats.db`
Windows: `C:/ARM/_uTun/utun2/tools/chatgui/build/chat_data/chats.db` (доступа нет)