1.1 каркас пакета: репозиторий, Protocol хранилища, границы общей части

[axisrow]

Задача

Создать третий репозиторий-пакет и определить его контракт с хранилищем —
фундамент для переезда общей части (#1416).

Область пакета — только общая часть

tg_messenger — независимый TUI-мессенджер (ставится сам по себе, один
аккаунт). Поэтому в пакет идёт только то, что нужно обоим проектам:

В пакет	Остаётся в фабрике
соединение, сессии	пул многих аккаунтов
модели сообщений, чтение истории, отправка	ротация, лизинг
защита от флуда	сбор постов (collector_*)
подписка на входящие события

Ключевое требование: пакет обязан работать БЕЗ фабрики вообще — один
аккаунт, своё хранилище по умолчанию, никакого AppContainer. Иначе
мессенджер перестанет быть самостоятельным продуктом.

Контракт хранилища

Связь с базой узкая и уже наполовину развязана: src/database/live_accounts.py
— 35 строк, две функции, обе уже принимают db: Any первым аргументом:

async def load_live_usable_accounts(db: Any, *, active_only: bool = False) -> list[Account]
async def account_row_exists(db: Any, phone: str) -> bool

Интерфейс получается почти сам собой — надо зафиксировать его явно (Protocol),
а не выводить из Any. Контракт должен допускать две конфигурации:
мессенджер со своим простым хранилищем и фабрика со своей базой.

Состав работ

1. Каркас репозитория: pyproject.toml, лицензия, CI (по образцу существующих),
   py.typed, версионирование.
2. Protocol хранилища: что именно пакету нужно от БД — данные аккаунта,
   запись/чтение flood_wait_until, персистентность resolve-backoff.
   Минимальный контракт, без протечки схемы фабрики.
   Плюс реализация по умолчанию для одиночного мессенджера.
3. Protocol/тип аккаунта — сейчас src.models.Account; в пакете нужен свой,
   чтобы не тянуть модели фабрики.
4. Решение о версионировании и пиннинге. ⚠️ Прецедент: tg-messenger объявлен
   как >=0.1.0, но нет тегов и changelog — фабрика фактически стоит
   на editable-чекауте соседнего проекта. Не повторять: точный пин + теги
   • changelog с первого дня.
5. Стратегия миграции: как фабрика и мессенджер будут переходить волнами,
   не ломаясь на промежуточных состояниях.

Acceptance Criteria

• Репозиторий создан, CI зелёный на пустом каркасе.
• Protocol хранилища зафиксирован и задокументирован; Any заменён
  на явный тип.
• Пакет не импортирует src.* фабрики — проверяется автоматически.
• Версионирование: теги + changelog + точный пин у потребителей.
• Задокументирован точный раздел: что в пакете (общая часть), что остаётся
  в фабрике (пул, ротация, лизинг, collector_*), что в мессенджере
  (TUI, веб-чат, автоответчик).
• Определён раздел backends.py: транспортная часть в пакет, пул-специфика
  в фабрику.
• Пакет работает без фабрики — проверено на конфигурации «один аккаунт,
  своё хранилище».
• Кода из фабрики в этой задаче не переносится — только каркас
  и контракт.

Файлы (для чтения, не правки)

• src/database/live_accounts.py — 35 строк, будущий Protocol
• src/telegram/client_pool.py, src/telegram/account_lease_pool.py —
  остаются в фабрике, но становятся потребителями пакета
• src/telegram/backends.py — требует разделения
• src/models.py — Account
• pyproject.toml, .importlinter — образцы конфигурации

Контекст

Этап 1.1 эпика #1416.

[axisrow]

⚠️ Область пересмотрена (2026-08-29)

Решение владельца: в пакет выносится только общая часть для обоих проектов,
а не весь слой Telegram. Цель — упростить структуру, чтобы стало меньше кода,
где теряться.

tg_messenger — независимый проект (обычный TUI-мессенджер, ставится сам
по себе, один аккаунт, без фабрики). Поэтому многоаккаунтная инфраструктура
в пакет не идёт.

Что	Куда
Соединение, сессии	пакет
Модели сообщений, чтение истории, отправка	пакет
Защита от флуда	пакет
Подписка на входящие события	пакет
Пул многих аккаунтов, ротация, лизинг	остаётся в фабрике
Сбор постов из каналов	остаётся в фабрике
TUI, веб-чат, автоответчик	остаётся в мессенджере

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