3.8.0: «database is locked» y los 753 que no se movieron, arreglados; fechas raras, escaneo profundo, buscar, otros discos, banco por fecha y compilar en el estudio

- Tras «Aplicar» en una carpeta grande el inventario se ponía al día con la base tomada más de diez minutos y
  «Buscar clips» se rendía con «database is locked». Ahora las preguntas al disco van antes y en paralelo y
  lo de dentro de cada carpeta se busca por índice: 1,3 s para 2.493 movimientos, mismas filas de archivos
  que antes y 183 carpetas que antes se perdían. La lectura de clips reintenta si la base está ocupada.
- Las fotos de «Alta» y «Baja» chocaban al juntarse en una carpeta: las subcarpetas con sentido se
  conservan, el plan avisa antes de dos archivos iguales en una fila, y un número entre dos palabras
  («Fiesta 6 Años») ya no se quita.
- Los fallos de «Aplicar» se agrupan por motivo y dicen qué hacer; el banco de material se explica en llano.
- Fechas raras (el reloj de una cámara), escaneo profundo, buscar en todos los clientes, traer lo que el
  cliente tiene en otros discos, el banco por temas o por fecha, y «Calcular de nuevo» más rápido.
- Mover reintenta un momento si el archivo está abierto un instante (lectura de clips, antivirus).
- .github/workflows/publicar.yml para compilar y publicar desde un PC del estudio; las pruebas devuelven
  error si algo falla.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -245,7 +245,37 @@ y nunca pisa un MP4 que ya exista; las raíces de unidad (`N:\`) ya se consultan
     bash publicar.sh              # sube los zips al NAS, deja el manifiesto en GitHub y despliega el OS
 
 `empaquetar.py` no deja salir un paquete con un binario sin firmar ni uno cuyo motor no arranque. Con
-`SOLO_LOCAL=si` construye sin tocar el manifiesto del OS (para ensayar).
+`SOLO_LOCAL=si` construye sin tocar el manifiesto del OS (para ensayar). `verificar_publicado.py` comprueba
+después lo que sirve el OS (versión, firma, que es el mismo manifiesto y la huella del paquete).
+
+### Compilar y publicar en el estudio
+
+`.github/workflows/publicar.yml` hace todo lo de arriba solo, en un PC de Windows del estudio registrado como
+«runner» propio de GitHub. No en las máquinas de GitHub: el NAS solo se alcanza desde la red del estudio, y la
+clave que firma las actualizaciones no tiene que salir de ese PC (quien la tenga puede mandar una actualización a
+todos los OrganiLAB instalados).
+
+Preparar el PC una vez (con la sesión del usuario que publicará):
+
+1. Python 3.12 (`py -3.12`), Git para Windows (trae Git Bash, que usa `publicar.sh`) y ffmpeg (el «full build»
+   de Gyan; si no está en la ruta de WinGet, la variable de entorno `FFMPEG_DIR` apunta a su carpeta `bin`).
+2. La clave de firma en `%USERPROFILE%\.labstream\organizador-firma.json` (copiada desde el PC donde está hoy, y
+   con copia de seguridad aparte), y la llave del NAS en `%USERPROFILE%\.ssh\editorias_nas`.
+3. Permiso de escritura en GitHub para `labstream-organizador` y `labstream-os` (Git Credential Manager, con la
+   cuenta de Labstream).
+4. En GitHub › `labstream-organizador` › Settings › Actions › Runners › «New self-hosted runner» › Windows: seguir
+   los pasos, y al configurarlo añadir la etiqueta `organilab`. Instalarlo como servicio con ese mismo usuario
+   (para que vea la clave y las llaves), en un PC que esté encendido.
+
+Publicar una versión: subir `VERSION` en `organizador.py`, y
+
+    git tag -a v3.8.0 -m "Lo que verán las copias instaladas al actualizar"
+    git push origin v3.8.0
+
+o en GitHub › Actions › «Publicar OrganiLAB» › «Run workflow», escribiendo las notas. El trabajo comprueba que la
+etiqueta y `VERSION` coinciden, pasa las cuatro baterías de pruebas, empaqueta, prueba el paquete arrancándolo,
+publica, comprueba lo publicado y guarda `manifiesto.json` en `main`. Si una prueba falla, se detiene ahí y no
+se publica nada.
 
 Cuando el OS sirve el manifiesto nuevo, cada copia instalada lo ve al abrirse (o al pulsar «Actualizar ahora»),
 descarga el zip «app» (15 MB), comprueba el sha256 y se sustituye sola sin tocar `datos\` ni `ffmpeg\`.
@@ -880,6 +910,55 @@ Pruebas: `prueba_orden.py` 24 casos (5 nuevos: pieza, bandeja, tarjeta con una c
 que rechazar, versiones con ffprobe simulado, y la pasada automática con sus frenos); `prueba_funcional.py`
 29 de 29 (3 nuevas, por la interfaz de verdad del servidor); `probar.py` 19 y `prueba_ventana.py` 18.
 
+3.8.0, lo que faltaba. Munka, después de la 3.7.0: «al hacer un cambio en el plan me debería dar un chequeo
+para saber que ya se hizo», «construye las mejoras que planteas» y, aplicando el plan de Vía Sumapaz, 753
+movimientos que no se pudieron y «database is locked» al buscar clips para convertir («lo más importante»).
+
+- **«database is locked» al buscar clips.** Después de «Aplicar» en una carpeta grande, el inventario se ponía
+  al día con la base tomada durante más de diez minutos (en Sumapaz, 2.493 movimientos): preguntaba al disco de
+  red dos veces por movimiento, a 41 ms con el NAS ocupado, y buscaba lo de dentro de cada carpeta recorriendo
+  la tabla entera. Mientras tanto «Buscar clips» esperaba un minuto y se rendía. Ahora lo que hay que preguntar
+  al disco se pregunta antes, todo a la vez y en paralelo, y lo de dentro de cada carpeta se busca por índice:
+  1,3 segundos para los 2.493 movimientos, con las mismas filas de archivos que la versión anterior (comparado
+  tabla por tabla) y 183 carpetas que la anterior perdía del inventario y sí existen en el disco. Y la lectura
+  de clips, si la base está ocupada, espera y reintenta. Leídos así los clips de Sumapaz: 2.760, 2.319
+  convertibles (1,97 TB, unos 0,33 TB convertidos, 145 de ellos BRAW).
+- **Los 753 que no se movieron**: cada evento de «Fotos varias» guarda la misma foto en «Alta» y en «Baja» con
+  el mismo nombre, y el plan juntaba las dos en una sola carpeta; la segunda chocaba con la primera y, como la
+  app nunca renombra, se quedaba donde estaba (no se perdió nada). Ahora las subcarpetas con sentido bajo una
+  sesión («Alta», «Baja», «Seleccionadas»…) se conservan debajo de la cámara, el plan avisa antes si dos archivos
+  de una misma fila acabarían en el mismo sitio, y «Fiesta 6 Años» ya no pierde el 6 (un número entre dos
+  palabras es parte del nombre; los prefijos y las fechas se siguen quitando).
+- **Los fallos de «Aplicar», explicados**: se agrupan por motivo (ya había un archivo con ese nombre, estaba
+  abierto en otro programa, sin permiso, ya no estaba, la copia entre discos no quedó completa, se cortó la red)
+  y cada grupo dice qué hacer, con ejemplos.
+- **El banco de material, en llano**: cada fila dice «69 clips de la URSA (BRAW) en el tema «Lanzamiento
+  Sumapaz» → se quedan en el mismo tema, en 2023-12-23 › URSA_BRAW», en vez de dos rutas largas; arriba, qué
+  hace el paso con un ejemplo, y qué quiere decir «probable» y «dudoso».
+- **Inicio, como lista con ✓**: lo hecho se queda en su sitio con «Hecho hoy a las 07:41: …» en vez de
+  desaparecer (el tipo de trabajo, el stock, los repetidos, la bandeja, convertir), arriba se cuentan los
+  hechos, y lo que acaba de pasar a hecho se ilumina. «Basura y proxies» deja de pedirse cuando lo que queda es
+  lo de «No tocar» o lo que va sin marcar.
+- **Fechas raras** (Revisar): las tandas de clips de una cámara con el reloj sin poner (2008, 2009…), con una
+  pista de su fecha real; se pone la del primer clip y la app corre los demás lo mismo. La corrección se guarda
+  por archivo (nombre y peso), sobrevive a volver a escanear y a que el plan los mueva, y se deshace.
+- **Escaneo profundo** (por defecto; se apaga en Ajustes): después de escanear, la app lee cada clip (códec,
+  duración, resolución) en segundo plano y solo lo nuevo.
+- **Buscar en todos**: el buscador de la barra lateral encuentra un archivo o una carpeta por su nombre en todas
+  las carpetas de clientes, con o sin tildes, y abre su carpeta.
+- **Otros discos**: si el cliente está también en otros discos (Vía Sumapaz: K:, Q: y dos en T:), Inicio lo
+  dice y deja traer cada sitio con copia comprobada; el original no se toca.
+- **El banco, por temas o por fecha**: en «Qué va a pasar» se elige; por fecha, cada grabación va a la
+  00_Grabacion de su mes con su tema de etiqueta.
+- **«Calcular de nuevo» más rápido**: las comprobaciones del plan contra el disco van al final y en paralelo; en
+  Sumapaz después de aplicar, de 58 s a 20 s.
+- **Compilar en el estudio**: `.github/workflows/publicar.yml` y la guía de arriba; las pruebas devuelven error
+  si algo falla, y `verificar_publicado.py` está en el repositorio.
+
+Pruebas: `prueba_orden.py` 38 casos (cuatro nuevos: «Alta» y «Baja», el reloj de una cámara y buscar, el banco
+por fecha, otros discos); `prueba_funcional.py` 33 de 33 (buscar y «Fechas raras» por la interfaz del servidor);
+`probar.py` 19 y `prueba_ventana.py` 18.
+
 3.7.0, la auditoría de Vía Sumapaz. Munka: «creo que el escáner de archivos fue superficial», «no me sale la
 forma de organización del material», «no hay reorganización y faltan funciones», y una captura de «Qué va a
 pasar» con el botón «Calcular» gris y ningún plan. Lo medido el 14-oct-2026 sobre `Y:\Sumapaz` (76.559