fix(install): la actualizacion de Windows decia que funciono y no cambiaba nada

Actualizar un servidor con el agente en una carpeta NO estandar terminaba en
verde y lo dejaba con la version anterior. Todo el camino de Windows
identificaba al agente por NOMBRE, mientras que lo unico que se actualiza se
identifica por RUTA; en cuanto las dos no coincidian, nada fallaba y nada
cambiaba.

- Se alinea la tarea programada con el binario instalado. `Start-ScheduledTask`
  ejecuta la ruta registrada en su accion, no el -Prefix: si difieren, se copiaba
  el binario nuevo en un sitio y se arrancaba el viejo del otro. Ahora se
  reapunta conservando disparador, principal, ajustes y argumentos; si no se
  puede corregir, FALLA — arrancar a sabiendas el binario anterior es peor.
- La confirmacion de arranque mira la RUTA del proceso. Un agente viejo que
  nunca se detuvo satisfacia igual de bien un `Get-Process -Name`. Si la ruta no
  es legible (un proceso de SYSTEM no la expone sin elevacion) se acepta por
  nombre y se avisa, en vez de revertir una actualizacion correcta por falta de
  informacion.
- Corregido Merge-EnvFile con un config\.env de UNA linea: al asignar la salida
  de un `if`, PowerShell desenrolla un array de un elemento a escalar, asi que
  $lines.Count reventaba con Set-StrictMode y la siembra abortaba la instalacion.

Nuevo scripts/emular-actualizacion-windows.ps1: monta un agente falso (un .exe
real que se queda vivo), una instalacion en una carpeta y una tarea apuntando a
otra, corre el instalador y dice si la actualizacion surtio efecto. Sin elevacion
y sin tocar la instalacion real de la maquina. Es lo que destapo los dos
defectos: contra el instalador anterior reproduce el sintoma exacto —codigo de
salida 0 y "El agente esta corriendo con el binario nuevo" sobre un servidor
intacto— y contra este confirma que ya surte efecto, sin tocar la tarea cuando
ya estaba bien.

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

tests/test_release_metadata.py

@@ -138,6 +138,38 @@ def test_install_ps1_respalda_y_revierte():
     assert "Remove-Item -LiteralPath $backup" in ps1
 
 
+def test_install_ps1_alinea_la_tarea_con_el_binario_instalado():
+    """
+    El fallo silencioso: reemplazar el binario es una operación por RUTA, pero
+    `Start-ScheduledTask` es por NOMBRE y ejecuta la ruta que la tarea lleva registrada. Con una
+    instalación fuera de la carpeta por omisión, eso copiaba el binario nuevo en un sitio y
+    arrancaba el viejo desde otro: el run terminaba en verde y el servidor seguía igual.
+
+    Se comprueba con `scripts/emular-actualizacion-windows.ps1`, que reproduce el escenario
+    completo; esto solo protege de que las piezas desaparezcan en un refactor.
+    """
+    ps1 = (ROOT / "install.ps1").read_text(encoding="utf-8")
+    assert "Sync-AgentTaskPath" in ps1
+    assert "Get-AgentTaskExecute" in ps1
+    # La comparación tiene que normalizar: la tarea guarda la ruta entrecomillada y NTFS no
+    # distingue mayúsculas, así que comparar las cadenas en crudo da falsos negativos.
+    assert "Test-SamePath" in ps1
+    # Y la confirmación de arranque tiene que mirar la RUTA del proceso, no solo su nombre.
+    assert "FromPrefix" in ps1
+
+
+def test_merge_env_file_no_se_desenrolla_con_una_sola_linea():
+    """
+    `$lines = if (...) { @(Get-Content ...) } else { @() }` desenrolla un array de UN elemento a
+    escalar al asignarlo, así que con un config\\.env de una sola línea `$lines.Count` reventaba
+    bajo Set-StrictMode y la siembra de credenciales abortaba la instalación. El `@()` tiene que
+    envolver el `if` COMPLETO.
+    """
+    ps1 = (ROOT / "install.ps1").read_text(encoding="utf-8")
+    assert "$lines = @(\n" in ps1, "el @() debe envolver el if completo, no solo el Get-Content"
+    assert "$lines = if (" not in ps1
+
+
 def test_el_arranque_automatico_de_windows_pide_headless():
     """
     La tarea ONSTART corre como SYSTEM, en la sesión 0, donde no hay escritorio interactivo. Es