fix: preserve requested transaction filter across pagination

[Flummy1]

Проблема

TransactionPreviewsBatch.next_batch() терял фильтр транзакций: первая страница приходила
отфильтрованной, а каждая следующая — со всей лентой транзакций. Молча, без исключения
и предупреждения.

batch = await bot.get_transactions(filter=TransactionFilter.WITHDRAW)
# batch.transactions — только выводы ✅

nxt = await batch.next_batch()
# nxt.transactions — выводы, пополнения, заказы, возвраты ❌

Последствие для потребителя — тихая порча данных: любой код, который постранично читает
отфильтрованную ленту, начиная со второй страницы получает не то, что запросил. Аккаунты,
чья история помещается на одну страницу (~25 транзакций), не затронуты — это и есть
характерный признак.

Причина

next_batch() восстанавливал фильтр из self.filter, а self.filter — это не запрошенное
значение, а значение, вычитанное из HTML ответа:

# funpayparsers/parsers/transaction_previews_parser.py
filter_ = self.tree.css('input[type="hidden"][name="filter"]')
filter=filter_[0].attributes.get('value') if filter_ else None

FunPay в части ответов не отдаёт скрытый input filter. Тогда self.filter становится
None, и выражение self.filter or '' расширяет фильтр с «выводы» до «всё»:

return await self.get_bound_bot().get_transactions(
    from_transaction_id=self.next_transaction_id,
    filter=self.filter or '',   # ← '' == TransactionFilter.ALL
)

Усугубляет ситуацию то, что TransactionFilter.ALL == '', то есть ложно в булевом
контексте. Поэтому любой fallback через or на этом enum некорректен по построению: он не
способен отличить «фильтр не применялся» от «фильтр неизвестен».

При этом GetTransactions вообще не передавал запрошенный фильтр в собираемый объект —
context не заполнялся.

Решение

Инвариант в кодовой базе уже сформулирован — просто не был применён к транзакциям.
GetSales пробрасывает дискриминатор через context метода, а OrderPreviewsBatch.next_batch()
громко падает на неизвестном типе вместо подстановки значения по умолчанию.

Транзакции приведены к тому же контракту:

1. GetTransactions передаёт context={'transaction_filter': method.filter} — запрошенное
   значение, уже нормализованное pydantic в enum (в том числе если пользователь передал строку).
2. TransactionPreviewsBatch.model_post_init отдаёт приоритет фильтру из запроса; значение
   из HTML остаётся только как fallback (например, для объекта, собранного вручную).
3. next_batch() передаёт фильтр явно и бросает ValueError, если фильтр неизвестен,
   вместо тихого расширения до ALL. Никаких проверок на «ложность» enum.
4. GetTransactionsPage помечает свой батч как TransactionFilter.ALL — страница баланса
   всегда отдаёт нефильтрованный список, поэтому пагинация оттуда продолжает работать.

Сопутствующий дефект (обнаружен при работе над основным): GetTransactions() без аргументов
падал с ValidationError, потому что from_transaction_id по умолчанию был None при поле
типа int. Значение по умолчанию исправлено на 0.

Изменения

Файл	Что
funpaybotengine/methods/get_transactions.py	проброс context, исправлен дефолт from_transaction_id
funpaybotengine/types/finances.py	приоритет запрошенного фильтра, громкий отказ в next_batch()
funpaybotengine/methods/get_transactions_page.py	батч страницы баланса помечен как ALL
pyproject.toml	секция [tool.pytest.ini_options], чтобы make test работал; pythonpath = ["."]
tests/test_transactions_pagination.py	регрессионный набор (новый)

Обратная совместимость

Меняется одно наблюдаемое поведение: next_batch() теперь бросает
ValueError('Unknown transaction filter.') вместо того, чтобы отдать неотфильтрованную
страницу. Это ровно тот случай, который раньше и приводил к порче данных, и он воспроизводится
только на батчах, собранных в обход GetTransactions / GetTransactionsPage.

batch.filter теперь при обычном использовании всегда содержит запрошенный enum, а не None.

Каллерский workaround (ручная пагинация с явным фильтром) продолжает работать и больше не нужен.

Проверки

uv run ruff check funpaybotengine tests     # passed
uv run ruff format --check funpaybotengine tests  # passed
uv run mypy funpaybotengine                 # Success: no issues found in 107 source files
uv run --extra tests pytest tests -q        # 10 passed

Регрессионный набор проверен на «мутацию»: против кода до фикса падают 7 из 10 тестов,
включая сквозной test_filtered_pagination_survives_a_response_without_filter_input, который
прогоняет настоящий TransactionPreviewsParser на ответе без скрытого input filter.

pythonpath = ["."] в конфиге pytest добавлен не для удобства: без него голый pytest
(вне uv run) импортирует funpaybotengine из установленного в окружении релиза, а не из
рабочего дерева, и тесты молча проверяют чужой код.

Зависимость

Ветка построена поверх #39 (chore/fix-ruff-mypy-strict) — база PR должна быть chore/fix-ruff-mypy-strict,
иначе в диффе окажутся чужие изменения. После вливания #39 базу можно переключить на dev.