Un agente anterior a 1.1.0 no reporta su install_path, así que el panel caía al
default de plataforma y ACTUALIZAR abortaba cuando la instalación vivía en otra
carpeta (p. ej. C:\Aduanasoft\CloudRestoreAS-win). Era un huevo-y-gallina: la
ruta se empieza a reportar en 1.1.x, que es justo lo que no se podía instalar.
Se agrega la captura manual de la ruta por servidor. No hace falta esquema nuevo
ni lógica de resolución nueva: el upsert del estado ya usa
install_path = COALESCE(EXCLUDED.install_path, actual), así que el valor
capturado sobrevive los reportes sin ruta del agente viejo, y resolveInstallPath
y cras-verify ya leen esa misma columna. Cuando el servidor quede en 1.1.x su
propio reporte lo sustituye por la ruta real.
De paso, dos fallos de configuración que costaron el diagnóstico:
- GITEA_TOKEN con los `<>` de la plantilla se veía como un 401 opaco de Gitea,
idéntico al de un token revocado. Se valida la forma antes de llamar, el
aviso sale al cargar la pantalla y 401 y 403 dejan de colapsar al mismo
texto. Un rechazo ahora deja línea en los logs: no dejaba ninguna.
- PANEL_PUBLIC_URL sin el puerto apuntaba a otro servicio. Esa URL se siembra
en el config/.env del destino también al ACTUALIZAR, así que rompería un
agente que ya reportaba: se avisa y se aborta antes de tocar el servidor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
