fix(bootstrap): escribir el sello de version lo primero, y hacerla visible en el log

Actualizar a 1.1.4 fallaba con "no escribio config\.version tras la
actualizacion" aunque el binario nuevo estuviera instalado y corriendo desde la
ruta correcta. La causa era el ORDEN dentro de ensure_runtime_layout(): el sello
iba al final, detras del re-despliegue de las deps embebidas (7-Zip y ODBC). Al
cambiar de version esas deps se re-copian ENTERAS, asi que el sello quedaba por
detras de esa copia y del desempaquetado del onefile de ~254 MB con el antivirus
escaneando cada archivo. El PANEL se rendia esperandolo y daba por fallida una
actualizacion que iba bien.

- El sello se escribe lo primero, en cuanto existen las carpetas. Es tambien mas
  honesto sobre lo que significa —"que binario esta corriendo"—, que es cierto
  desde que el proceso arranca. El sello de DEPS sigue yendo al final, donde su
  comentario explica por que: si la copia falla a medias, el proximo arranque
  reintenta en vez de quedar marcado como al dia.
- La version va en la PRIMERA linea del log de arranque. Permite comprobar que
  binario corre de verdad mirando solo config/logs, sin depender del sello ni del
  reporte al panel: verificar una actualizacion deja de obligar a creerse lo que
  diga otro sistema.

La prueba nueva observa el estado del sello EN EL MOMENTO en que empieza la copia
de deps, no al final, que es la unica forma de fijar el orden. Comprobado que
muerde: devolviendo el sello al final falla con `assert None == '1.1.5'`.

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

CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## [1.1.5] - 2026-07-31
+
+### La versión ahora es comprobable, y el sello deja de llegar tarde
+
+Actualizar a 1.1.4 fallaba con *"no escribió `config\.version` tras la actualización"* aunque el
+binario nuevo sí estuviera instalado y corriendo desde la ruta correcta. La causa era el **orden**
+dentro de `ensure_runtime_layout()`: el sello de versión se escribía al final, detrás del
+re-despliegue de las dependencias embebidas (7-Zip y ODBC). Y al cambiar de versión esas deps se
+re-copian **enteras**, así que el sello quedaba por detrás de esa copia *y* del desempaquetado del
+onefile de ~254 MB, con el antivirus escaneando cada archivo. El PANEL se rendía esperándolo y daba
+por fallida una actualización que iba bien.
+
+- **El sello se escribe lo primero**, en cuanto existen las carpetas. Es además más honesto sobre lo
+  que significa —"qué binario está corriendo"—, que es cierto desde que el proceso arranca. Si el
+  despliegue de deps fallara después, su propio sello (que sigue yendo al final) lo detecta y el
+  siguiente arranque reintenta.
+- **La versión va en la primera línea del log de arranque.** Permite comprobar qué binario corre de
+  verdad mirando solo `config/logs`, sin depender del sello ni del reporte al panel. Verificar una
+  actualización ya no obliga a creerse lo que diga otro sistema.
+
 ## [1.1.4] - 2026-07-31
 
 Recoge todo lo que sigue de esta sección y **sustituye a 1.1.3**, cuyo artefacto publicado se generó