Добавить startup recovery для resync цепочек

Dev_Docs/Blockchain/sync-between-servers.md

@@ -82,7 +82,52 @@
    - цепочка подтягивается заново с `0` через `GetBlockchainBlock`.
    - обычный `AddBlock` на эту цепочку в этот момент возвращает `chain_resync_in_progress`.
 
-### 4.4 Зачем понадобился `GetSyncUserProfile`
+### 4.4 Как именно работает full resync
+
+Full resync запускается только тогда, когда:
+
+- локальная chain отстаёт и обычная докачка хвоста упирается в `bad_prev_hash` или `bad_block_number`;
+- либо высота цепочек одинаковая, но удалённая версия сильнее по правилу:
+  - `lastBlockNumber`;
+  - `fileSizeBytes`;
+  - `lastBlockHash`.
+
+Порядок действий:
+
+1. Ставится in-memory guard на `blockchainName`.
+2. Создаётся marker-file `<blockchainName>.resync_pending`.
+3. Обычный `AddBlock` на эту chain временно получает `chain_resync_in_progress`.
+4. Вызывается атомарный SQL cleanup одной chain:
+   - уменьшаются чужие `likes_count` и `replies_count`;
+   - удаляются локальные derived-state записи этой chain;
+   - удаляются `blocks` и `blockchain_state` этой chain.
+5. Удаляются файлы `<blockchainName>.bch` и `<blockchainName>.tmp_bch`.
+6. Локальная chain создаётся заново через `GetSyncUserProfile` или через Solana import, если `sync.importUserProfileFromPartner.enabled=false`.
+7. Chain replay-ится с `0` через `GetBlockchainBlock`.
+8. Если всё прошло успешно, marker-file удаляется.
+9. Если на любом шаге произошёл сбой, marker-file остаётся на диске, и сервер добивает эту chain при следующем старте.
+
+Важно:
+
+- full resync не делает умный rollback по одному блоку;
+- full resync не трогает DM-таблицы и `solana_users`;
+- висячие cross-chain ссылки считаются допустимым поведением системы.
+
+### 4.5 Startup recovery по marker-file
+
+При старте сервер идёт в таком порядке:
+
+1. `BlockchainTmpRecoveryOnStartup` для `*.tmp_bch`;
+2. `BlockchainResyncRecoveryOnStartup` для `*.resync_pending`;
+3. только потом поднимается обычный сервер и запускается `PeriodicBlockchainSyncService`.
+
+Если marker-file существует:
+
+- сервер не должен начинать обычную работу поверх этой chain;
+- recovery снова выполняет cleanup и replay с нуля;
+- если recovery не завершился, marker остаётся, и сервер не переходит к обычному режиму для этой chain.
+
+### 4.6 Зачем понадобился `GetSyncUserProfile`
 
 Изначально подготовка локальной цепочки делалась через Solana:
 
@@ -100,7 +145,7 @@
 
 Это временная практическая заплатка, чтобы clean-start sync не зависел от rate limit внешнего Solana endpoint.
 
-### 4.5 Что делает настройка `sync.importUserProfileFromPartner.enabled`
+### 4.7 Что делает настройка `sync.importUserProfileFromPartner.enabled`
 
 - `false` — стандартный режим, подготовка локального пользователя идёт через Solana PDA;
 - `true` — sync-режим обхода Solana, локальный пользователь создаётся по server-to-server `GetSyncUserProfile`.
@@ -169,11 +214,12 @@
 | Push блоков блокчейна партнёрам | ✅ Реализована базовая one-shot версия |
 | Periodic backfill отсутствующего хвоста | ✅ Реализовано |
 | Разрешение рассинхрона / divergence | ✅ Реализована базовая full-resync схема во время periodic sync |
+| Startup recovery по `*.resync_pending` marker-file | ✅ Реализовано |
 | Маршрутизация DM через access_servers | Нужна реализация (заглушка) |
 
 Текущая версия сервера уже умеет базовую синхронизацию блокчейнов между партнёрами.
-Не реализованы ещё DM-sync, постоянные server-to-server соединения и recovery при старте по marker-file для resync.
+Не реализованы ещё DM-sync и постоянные server-to-server соединения.
 
 Следующие отдельные шаги после текущего этапа:
-- добавить startup recovery по marker-file для resync-цепочек;
 - вернуть обычному `AddBlock` настоящую `tmp_bch`-схему записи и recovery при резком рестарте.
+- отдельно проверить full-resync и startup-recovery на реальном тестовом прогоне после ручного удаления БД/файлов.