Три места продолжали брать egress из статичного SCRAPER_PROXY_URL, который не знает
про scrape_proxy_source_bans. Тот же класс, что #2796 (Домклик, ноль лотов четверо
суток) и #2798/#2821 (Циан, 403 пятнадцать суток при «узел здоров» в пуле).
1. cian_price_history (ручка POST /admin/scrape/cian-price-history) — узел из пула
+ вердикт обратно (mark_banned на 403, mark_health, release). Ловушка, из-за
которой одного `proxy_provider=` мало: USE_PROXY_POOL_CURL задан только контейнеру
scraper, а ручка живёт в backend, где флага нет — curl_proxy_url молча ушёл бы на
env. Отсюда _PoolCurlConfig; иначе правка была бы зелёной и без эффекта.
Пул пуст в проде → отказ до HTTP и разрыв батча, а не 50 попыток по 5 секунд.
2. GET /admin/scraper/health показывал settings.scraper_proxy_url как «прокси
источника», пока трафик после #2825/#2831 выбирается пулом по запросу. Теперь тот
же резолвер, что у боевых путей; пул исчерпан для источника → пусто, а не статичный
узел (зелёная строка на месте отказа хуже пустой). Вердикт пулу отсюда НЕ уходит:
ipify-проба про доступность ipify, а не про репутацию узла у площадки (#2805).
3. resolve_cian_zhk_url_via_search — вторая нога обогащения ЖК: #2767 перевёл на пул
только fetch_newbuilding, резолв ЖК-url остался на config.cian_proxy_url. Плюс 403
там гасился в `return None` — узел получал mark_health(ok=True) и оставался в выдаче
Циану (механика #2700). Сейчас ветка спящая: resolved_zhk_url=0 во всех 59 прогонах.
Заодно удалён мёртвый resolve_cian_zhk_url: путь /zhk/<id>/ 404-ит с #972, вызывающих
не было ни одного, egress тоже был мимо пула — чинить незачем, удалить честнее.
Тесты красные на старом коде поведенчески (пул не получил вердикт / панель показала
static-env-node вместо пулового узла), не на отсутствии нового имени.
Refs #2830
