docs: la tarea programada tiene que apuntar a lo que se instalo

BUILD.md gana la seccion del fallo silencioso y como reproducirlo con
scripts/emular-actualizacion-windows.ps1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

BUILD.md

@@ -222,6 +222,30 @@ Reemplazar el binario de un servidor en producción no puede dejarlo sin restaur
 3. **Se confirma que el agente volvió a arrancar** y, si no, se **revierte** al binario anterior.
    El respaldo solo se descarta tras esa confirmación.
 
+### La tarea programada tiene que apuntar a lo que se instaló
+
+Reemplazar el binario es una operación por **ruta**; `Start-ScheduledTask` es por **nombre** y
+ejecuta la ruta que la tarea lleva registrada en su acción. Cuando las dos no coinciden —una
+instalación fuera de la carpeta por omisión, o movida de sitio— se copiaba el binario nuevo en un
+lado y se arrancaba el viejo del otro: **el run terminaba en verde y el servidor seguía igual**.
+
+`install.ps1` compara la acción de la tarea con el `-Prefix` y la **reapunta** si difieren,
+conservando disparador, principal, ajustes y argumentos. Si no puede corregirla, falla: arrancar a
+sabiendas el binario anterior es peor que abortar. Y la confirmación de arranque mira la **ruta**
+del proceso, no solo su nombre — un agente viejo que nunca se detuvo satisface igual de bien un
+`Get-Process -Name CloudRestoreAS`.
+
+Para reproducirlo y comprobarlo sin un servidor, desde WSL o Windows:
+
+```powershell
+scripts\emular-actualizacion-windows.ps1 -Installer .\install.ps1                      # caso roto
+scripts\emular-actualizacion-windows.ps1 -Installer .\install.ps1 -Escenario alineada  # caso normal
+```
+
+Monta un agente falso (un `.exe` real que se queda vivo), una instalación en una carpeta y una
+tarea apuntando a otra, corre el instalador y dice si la actualización surtió efecto. No necesita
+elevación ni toca la instalación real de la máquina.
+
 `-UpdateInPlace` además no vuelve a registrar la tarea (así no pisa ajustes hechos sobre ella) y
 se salta el bootstrap: una segunda instancia purgaría el `Temp\` de la que está viva. Es el modo
 que usa el PANEL para actualizar.

CHANGELOG.md

@@ -2,6 +2,27 @@
 
 ## [Sin publicar]
 
+### La actualización de Windows decía que funcionó y no cambiaba nada
+
+Actualizar sobre un servidor con el agente en una carpeta **no estándar** terminaba en verde y
+dejaba el servidor con la versión anterior. La causa: todo el camino de Windows identificaba al
+agente por **nombre**, mientras que lo único que se actualiza se identifica por **ruta**.
+
+- **`install.ps1` alinea la tarea programada con el binario instalado.** `Start-ScheduledTask`
+  ejecuta la ruta registrada en la acción de la tarea, no el `-Prefix`: si difieren, se copiaba el
+  binario nuevo en un sitio y se arrancaba el viejo del otro. Ahora se reapunta la tarea
+  conservando disparador, principal, ajustes y argumentos; si no se puede corregir, **falla**.
+- **La confirmación de arranque mira la ruta del proceso**, no solo su nombre. Un agente viejo que
+  nunca se detuvo satisfacía igual de bien un `Get-Process -Name CloudRestoreAS`. Si la ruta no es
+  legible —un proceso de SYSTEM no la expone a una cuenta sin elevación— se acepta por nombre y se
+  avisa, en vez de revertir una actualización correcta por falta de información.
+- **Nuevo `scripts/emular-actualizacion-windows.ps1`**: reproduce el escenario completo con un
+  agente falso, sin elevación y sin tocar la instalación real de la máquina. Es lo que destapó este
+  defecto y el siguiente.
+- **Corregido `Merge-EnvFile` con un `config\.env` de una sola línea.** Al asignar la salida de un
+  `if`, PowerShell desenrolla un array de un elemento a escalar, así que `$lines.Count` reventaba
+  bajo `Set-StrictMode` y la siembra de credenciales abortaba la instalación.
+
 ### Instalación y actualización desatendidas en Windows
 
 El instalador de Windows nunca recibió la maquinaria de actualización segura que sí tiene