Enhance proxy handling and error reporting in collection process

- Introduced a `Via` field in `ParseError` to indicate the proxy address used during requests, improving clarity on error contexts.
- Updated `ProxyPool` to prioritize confirmed live proxies while available, ensuring more reliable proxy selection and reducing connection timeouts.
- Implemented fallback logic to allow the use of unconfirmed proxies when no confirmed ones are available, preventing collection stalls.
- Adjusted logging in `CollectLogEntryViewModel` to include proxy details, enhancing error visibility for users.
- Added unit tests to verify new proxy selection logic and ensure correct behavior under various conditions.

These changes improve the robustness of the proxy management system and enhance the overall user experience by providing clearer error messages and more efficient proxy usage.

docs/collecting.md

@@ -56,6 +56,9 @@
   `ConcurrentQueue`, слив под `_flushGate`, иначе две гонки-выгрузки перемешают строки местами.
 - **Строка хранит ключ и аргументы, а не готовое предложение** — смена языка посреди прогона иначе
   оставит половину журнала по-английски. Литеральная половина (адрес, размер) не переводится никогда.
+- **Прокси попытки живёт в `ParseError.Via`** и печатается в строке как `via {адрес}`: «сайт ответил
+  404» через подтверждённую прокси и через ту, с которой никто не разговаривал, — разные диагнозы, а
+  без этого поля разница невидима.
 - **Адрес неудачи живёт в `ParseError.Subject`.** В `Message` его нет и быть не может: у шаблона
   перевода фиксированные подстановки. Без него журнал говорит «сайт ответил 404» и не говорит, на
   каком из десяти тысяч id.

docs/proxies.md

@@ -12,9 +12,17 @@
 
 - **`ProxyPool` переиспользует существующие `ProxyEntry` по `Endpoint.Key`** — иначе перезагрузка
   списка стирала бы статистику, а публичные фиды переиздаются каждые несколько минут.
-- **Доступность определяется карантином, а не `Health`.** `Health` — «что видели в последний раз»;
-  исключать всё когда-либо упавшее значит потерять прокси после первой осечки. Уже было багом, ловит
-  `A_failing_proxy_is_quarantined_and_comes_back_later`.
+- **Выдаются только подтверждённо живые, пока такие есть.** Сортировки «живые вперёд» не хватало:
+  её видит только липкая стратегия, берущая голову списка, а round-robin и взвешенный выбор тянут из
+  всего набора — то есть из пары тысяч непроверенных адресов, и почти каждый запрос платил полный
+  connect-таймаут, чтобы это выяснить. Теперь «живых N» на странице и то, куда реально ходит сбор, —
+  одно и то же число.
+- **Фолбэк на всё доступное, когда живых нет.** Непроверенная ≠ мёртвая: на холодном пуле строгий
+  фильтр не выдал бы ничего и сбор просто встал бы, не попробовав. Ответившая на этом пути прокси
+  сама себя переводит в живые.
+- **Карантин остаётся отдельным механизмом от `Health`.** `Health` — «что видели в последний раз»;
+  исключать навсегда всё когда-либо упавшее значит потерять прокси после первой осечки. Уже было
+  багом, ловит `A_failing_proxy_is_quarantined_and_comes_back_later`.
 - **`LiveCount` считает только `Alive` и не в карантине.** На нём висит гейт сбора, поэтому
   «доступна» (окно истекло) и «живая» намеренно расходятся: гейт не должен открываться от одного лишь
   истечения окна.