fix: диагностика перестаёт врать — падения маршрутов и потеря секрета (#38)

Два дефекта одного класса: состояние, которое не отражает реальность. Оба
найдены по данным из #32 и #37.

#32. Присланный лог показывал «сбоев 0» при том, что DC2 и DC4 всегда шли через
«Запасной Telegram IP», а DC203 всегда через «Системный DNS» — то есть
основные закреплённые адреса не использовались ни разу. Причина в счётчике:
ws_failures растёт только когда упали ВСЕ маршруты и соединение не состоялось.
Падения отдельных маршрутов через record_failure не попадали никуда, поэтому
перебор с откатом на запасной адрес выглядел как полное отсутствие проблем.

Добавлен route_failures: растёт на каждое падение маршрута, виден в строке
статуса CLI и в диагностике интерфейса. Теперь по логу сразу видно, что
закреплённый адрес мёртв, а не приходится это выводить.

#37. Симптом: Telegram пишет «прокси настроен неверно и будет отключён», при
этом Check status показывает Available. Это картина несовпадения секрета: TCP
проходит, init не разбирается под другим секретом, соединение закрывается.

Секрет мог меняться молча:

  #[cfg(not(unix))]
  fn write_secret_file(path: &Path, value: &str) {
      let _ = std::fs::write(path, value);   // ошибка выброшена
  }

create_dir_all рядом — так же. Если запись в %APPDATA%\TGLock\secret не
удавалась, программа генерировала новый секрет при каждом запуске и ничего об
этом не сообщала.

Теперь write_secret_file возвращает Result, load_or_create_secret_at отдаёт
StoredSecret с полем write_error, а оба интерфейса показывают предупреждение:
CLI строкой при старте, GUI записью в журнал. Прокси при этом продолжает
работать — просто до перезапуска.

Тесты: every_route_failure_is_counted, a_failed_write_is_reported_instead_of
_swallowed (родитель пути — файл, поэтому каталог не создать),
a_successful_write_reports_no_error (секрет переживает второй запуск).

В диагностике интерфейса добавлена подсказка: падения маршрутов больше нуля
при работающем Telegram — норма, значит закреплённый адрес недоступен и
подключение идёт через запасной.

Co-authored-by: by-sonic <171230345+by-sonic@users.noreply.github.com>

ui/main.ts

@@ -10,6 +10,7 @@ type Status = {
   dataCenter: number | null;
   route: string;
   failures: number;
+  routeFailures: number;
   uptimeSeconds: number;
   port: number;
   logs: LogLine[];
@@ -37,6 +38,7 @@ let status: Status = {
   dataCenter: null,
   route: "Маршрут ещё не выбран",
   failures: 0,
+  routeFailures: 0,
   uptimeSeconds: 0,
   port: 1080,
   logs: [],
@@ -261,8 +263,18 @@ function renderDiagnostics(): void {
           <span>Время работы</span>
           <strong class="time">${formatUptime(status.uptimeSeconds)}</strong>
         </article>
+        <article class="metric-card">
+          <span>Падений маршрутов</span>
+          <strong>${status.routeFailures}</strong>
+        </article>
       </div>
 
+      <p class="field-hint">
+        «Падений маршрутов» больше нуля при работающем Telegram — это норма:
+        значит закреплённый адрес недоступен и подключение идёт через запасной.
+        Число в багрепорте помогает понять, что именно перебиралось.
+      </p>
+
       <div class="log-panel">
         <div class="log-heading">
           <span>Последние события</span>