1.4 волна C: перенос пула соединений и транспорта (client_pool, backends, lifecycle, dialogs)

[axisrow]

Задача

Перенести пул соединений и транспортный слой — самая связанная волна,
делается последней.

Модули

Модуль	Строк	Связей с src/
src/telegram/pool_dialogs.py	1993	7
src/telegram/backends.py	1030	8
src/telegram/pool_lifecycle.py	692	11
src/telegram/client_pool.py	210	19
src/telegram/account_lease_pool.py	191	4

~4100 строк. client_pool.py — рекордсмен по связности (19), но сам по себе мал:
это композиция миксинов (после #1046), а не логика.

Что здесь сложного

• Лизинг ≠ подключение. Соединения в пуле постоянные
  (pool_lifecycle.py:611, disconnect_on_close=False); лиз — это резервация
  аккаунта под операцию, а не поднятие связи. Сохранить эту семантику.
• Подмена объекта клиента. pool_lifecycle.py:507, 548, 600 молча заменяют
  clients[phone] на новый TelegramTransportSession. Это уже сейчас ловушка
  (для будущего слушателя — критичная), при переезде легко потерять.
• Три уровня реконнекта с разной семантикой: авто-реконнект Telethon,
  reconnect_phone, force_reconnect_phone.
• pool_dialogs.py — почти 2000 строк, содержит 34 точки вызова прогрева
  диалогов (операция, дающая 85 % всех флудов). Кандидат на разбиение,
  но не в рамках переезда — переносить как есть, чтобы диф был читаемым.

Acceptance Criteria

• Модули перенесены, поведение идентично.
• Семантика лизинга сохранена: лиз не рвёт соединение, флуд не рвёт соединение.
• Все три пути реконнекта работают, покрыты тестами.
• Места подмены clients[phone] явно задокументированы в пакете как
  известная ловушка (пригодится для этапа 2).
• lint-imports зелёный; контракт «энтрипоинты не импортируют telethon»
  сохранён и распространён на новый пакет.
• Полный прогон тестов обоих проектов.

Контекст

Этап 1.4 эпика #1416. Зависит от 1.1-1.3.

[axisrow]

Закрыто как неактуальное — область пакета пересмотрена (2026-08-29)

Задача была про перенос пула соединений и транспорта (client_pool, backends,
pool_lifecycle, pool_dialogs, account_lease_pool, ~4100 строк) в общий пакет.

Решение владельца отменяет это. В пакет выносится только общая часть для
обоих проектов, а tg_messenger — независимый TUI-мессенджер на одном
аккаунте. Многоаккаунтная инфраструктура ему не нужна, поэтому:

• пул, ротация, лизинг остаются в фабрике — потребитель один;
• в пакет идёт то, что нужно обоим: соединение, сессии, модели сообщений,
  чтение/отправка, защита от флуда, подписка на события.

Транспорт (backends.py) частично попадает в общую часть — но не целиком
и не вместе с пулом. Конкретный раздел определяется в #1420 при фиксации
контракта пакета, отдельной задачи на «перенос волны C» не требуется.

Подробности — комментарий к эпику #1416.