test: --resume-dir не покрыт — проверка granularity/period и защита завершённого прогона

[axisrow]

Что не покрыто

Найдено мутационным тестированием при проверке PR #50. Дыра предсуществующая — воспроизводится и на main (813243e), рефакторинг её не вносил.

collector.py, ветка --resume-dir:

if manifest.granularity is not granularity or manifest.requested_period != requested_period:
    raise InvalidRequestError(
        "--resume-dir was created with a different dynamics granularity or requested period"
    )

Замена условия на if False: не роняет ни одного из 190 тестов.

Почему это важно

Это защита от порчи данных, а не косметика. --resume-dir дозаписывает виды в существующий каталог прогона. Если пользователь возобновит прогон с другой гранулярностью или другим окном дат, в один каталог лягут parquet-файлы от разных запросов, а manifest.json опишет их одним набором метаданных. Молча — потому что каждый отдельный файл будет корректен.

Соседняя проверка того же класса (prepare_resume_directory, отказ при несовпадении фразы/региона) покрыта тестами; эта — нет.

Второе, поменьше

Ранний возврат «полный прогон не переписываем»:

if not pending_views:
    return _PreparedRun(..., resumed=True)   # на main: return CollectionResult(...)

Его удаление тоже не роняет тесты. Комментарий рядом объясняет назначение: у завершённого прогона source_url и updated_at должны описывать последнюю фактическую запись, а не факт повторного запуска.

Что нужно

1. Тест: --resume-dir на каталог, созданный с другой гранулярностью → InvalidRequestError. Отдельно — с другим requested_period.
2. Тест: повторный --resume-dir на завершённый прогон не переписывает manifest.json (сверить updated_at до и после).
3. Обе мутации (if False: на проверке; удаление раннего возврата) обязаны краснеть.

Оба сценария — про --resume-dir, поэтому логично закрыть одним PR.

[axisrow]

Третья непокрытая гарантия (та же природа)

Найдено при проверке PR #49. Тоже предсуществующее — воспроизводится на main (813243e).

Политика ошибок батча: except Exception для изоляции одной фразы. Замена на except BaseException не роняет ни одного из 190 тестов.

Между тем это заявленная гарантия — докстринг говорит прямо: «BaseException intentionally is not caught», а комментарий рядом: «BaseException (KeyboardInterrupt, SystemExit) deliberately still propagates».

Что ломается на практике: пользователь жмёт Ctrl+C посреди батча — KeyboardInterrupt попадает в изоляцию фразы, записывается как обычный PhraseFailure, и батч продолжает работать со следующей фразой. Прервать сбор станет невозможно без нескольких Ctrl+C подряд.

Тест: батч, где _collect_one кидает KeyboardInterrupt → исключение обязано выйти наружу, следующая фраза не должна начинаться. Мутация except BaseException обязана краснеть.

---

Общая черта всех трёх пунктов этой issue: гарантия описана в комментарии, но не проверена тестом. Комментарий фиксирует намерение автора, а держится оно только на том, что никто не тронет строку.