`assert_called_once_with(source=..., endpoint=...)` требует, чтобы других
аргументов у вызова НЕ БЫЛО. Тем самым тест закреплял ровно тот дефект, который
чинит этот PR: браузерный фетчер обязан был строиться без проводки пула, иначе
CI краснел.
Заменено на проверку вхождения: source и endpoint по-прежнему сверяются, плюс
явно требуется наличие proxy_provider/use_pool/environment — то, без чего
прогон уходит мимо пула (proxy_lease_id=None, 5 блоков из 5 при здоровом пуле).
Прогон: 277 тестов зелёные, ruff чист.
Ветка browser_mode в avito_detail_backfill конструировала BrowserFetcher без
proxy_provider/use_pool/environment. Без них фетчер не кладёт "proxy" в тело
POST /fetch, сайдкар берёт свой env-прокси, и прогон уходит мимо пула целиком:
ни выбора узла по affinity, ни учёта scrape_proxy_source_bans, ни ротации при
блоке. В логе это ровно `proxy_lease_id=None`.
Ровно этот дефект чинили рядом — #2698 в house_imv_backfill, где он держал
35 отказов из 35 попыток в каждом прогоне полтора месяца, пока соседние свипы
через ТОТ ЖЕ сайдкар тянули сотни объявлений. Здесь он остался.
Замер 27.08, прогон 5098:
mode=browser, proxy_lease_id=None
BLOCKED #1..#5 подряд — firewall/soft-block (browser-mode)
ABORT — 5 consecutive blocks, enriched=0 attempted=5
При этом пул здоров — 4 узла, все ok, ни один не занят, браузерная проверка
пройдена в то же утро. А тот же URL Авито через прокси отдаёт 200 и 3.3 МБ
страницы. То есть площадка нас пускала, запрос шёл не оттуда.
Это объясняет, почему предыдущая правка (#3143, прокси в повторах curl-пути)
не восстановила сбор: боевой режим бэкфилла — browser, и он до curl-веток
вообще не доходит.
Три теста: конструктор на месте (страховка от проверки пустоты), все три
аргумента проводки передаются, use_pool читается из конфига а не зашит
константой (зашитый True отнял бы у владельца выключатель, зашитый False вернул
бы дефект незаметно). Проверил красноту на коде без проводки.
Прогон: 113 тестов зелёные, ruff чист.
Refs #3045, #3034, #2698
