Баг: дашборд показывает «HAPI Server (not available)» при рабочем hapi

[axisrow]

Симптом

Когда hapi установлен и реально работает (relay-туннель поднят, runner запущен), дашборд всё равно показывает пункт меню «HAPI Server (not available)» вместо рабочей ссылки.

Воспроизведено на проде: приложение bemyownbot (Dokku, образ из main a92c180, INSTALL_HAPI=true, HAPI_RUNNER_ENABLED=true). Туннель https://<id>.relay.hapi.run активен, в логах виден рабочий runner, но дашборд держит disabled-заглушку.

Корневая причина

Дашборд (app/ttydproxy/views.py:61-67) рендерит ссылку из файла HAPI_URL_FILE (по умолчанию /home/hapi/url). Если файла нет → показывается «not available».

Этот файл создаёт entrypoint.sh, но логика хрупкая и одноразовая:

1. На старте entrypoint делает rm -f url-файла (строки ~197-198), чтобы не показывать stale-ссылку.
2. Фоновый цикл for i in $(seq 1 60) (60 секунд) ждёт, пока в server.log появится https://<id>.relay.hapi.run И в settings.json появится cliApiToken, и только тогда записывает url-файл.

Проблема: relay-URL пишется в лог только ПОСЛЕ установки туннеля. Если к моменту истечения 60 попыток обе части ещё не совпали (или совпали с задержкой), цикл завершается, url-файл не создаётся и больше никогда не пересоздаётся (цикл живёт только на старте). Дашборд навсегда показывает «not available», хотя hapi полностью рабочий.

Диагностика на bemyownbot (подтверждение)

• /home/hapi/url — отсутствует.
• server.log содержит настоящий https://qaexdwhhawbxm4c4.relay.hapi.run (дважды).
• settings.json содержит cliApiToken.
• Фоновый extraction-цикл уже мёртв (контейнер живёт >1300с), файл не пересоздаётся.
• Т.е. обе части данных есть, но цикл их не дождался/разошёлся по времени → файл потерян навсегда.

Предлагаемое решение

• Сделать запись url-файла устойчивой, а не one-shot 60с: увеличить/убрать лимит, либо перевести на периодическую проверку (например, демон, который обновляет url-файл при появлении/смене relay-URL).
• Либо генерировать ссылку дашборда на лету при рендере меню (читать relay-URL из server.log/settings.json в момент запроса), а не полагаться на заранее записанный файл.
• Сбрасывать stale-url только если новый hapi реально не стартует (а не безусловным rm -f в начале).

Связано

• Полноценный запуск без hapi (headless / только веб-терминал) #63 (запуск без hapi) — обратная сторона той же логики url-файла/«not available».
• Сделать модульную систему #57 / PR feat: модульная сборка образа через build-time флаги INSTALL_* (#57) #62 — модульная сборка.

Приоритет: high.