Submodule vendor/visionsuite: da visionsuite a TieVision-Core, pin 4c178cf (#74)

Il repo e' stato rinominato il 15/10/2026 (TieVision-Core#329): .gitmodules punta
al nuovo URL, il pin passa da cdc7a14 a 4c178cf, CLAUDE.md e il commento di
scripts/camera_service.py seguono la divisione (vs-gui e vs-assistant in
TieVision-Studio e TieVision-Assistant). Test visione: 29 passed prima e dopo.

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

.gitmodules

@@ -1,3 +1,3 @@
 [submodule "vendor/visionsuite"]
 	path = vendor/visionsuite
-	url = ssh://git@git.tielogic.xyz:222/Adriano/visionsuite.git
+	url = ssh://git@git.tielogic.xyz:222/Adriano/TieVision-Core.git

CLAUDE.md

@@ -287,9 +287,9 @@ Nginx (dev): gzip abilitato, `client_max_body_size 50M`, `proxy_read_timeout 120
 
 ## Visione (V3.0.0)
 
-Il runner di visione (`src/vision/`) e il suo worker FastAPI (`src/vision_worker/`) dipendono da `vendor/visionsuite`, un **submodule** su `ssh://git.tielogic.xyz:222`: un `git clone` senza `--recurse-submodules` lascia la cartella vuota (chi ha già clonato: `git submodule update --init`). Le librerie di VisionSuite richiedono **Python 3.13**, mentre backend e frontend restano su Python 3.11 — è un albero a parte nel monorepo, isolato con il proprio extra `uv`.
+Il runner di visione (`src/vision/`) e il suo worker FastAPI (`src/vision_worker/`) dipendono da `vendor/visionsuite`, un **submodule** che punta al repo TieVision-Core (`ssh://git@git.tielogic.xyz:222/Adriano/TieVision-Core.git`, ex visionsuite, rinominato il 15/10/2026; `vs-gui` e `vs-assistant` sono ora in TieVision-Studio e TieVision-Assistant, che TieMeasureFlow non usa; il path resta `vendor/visionsuite`): un `git clone` senza `--recurse-submodules` lascia la cartella vuota (chi ha già clonato: `git submodule update --init`). Le librerie di VisionSuite richiedono **Python 3.13**, mentre backend e frontend restano su Python 3.11 — è un albero a parte nel monorepo, isolato con il proprio extra `uv`.
 
-Regola (Adriano, 07/10/2026): il submodule `vendor/visionsuite` segue `origin/main`: a ogni integrazione si porta all'ultimo commit (`git -C vendor/visionsuite fetch origin && git -C vendor/visionsuite checkout origin/main`) e si rilanciano i test della visione. Pin attuale: bc0df16.
+Regola (Adriano, 07/10/2026): il submodule `vendor/visionsuite` segue `origin/main`: a ogni integrazione si porta all'ultimo commit (`git -C vendor/visionsuite fetch origin && git -C vendor/visionsuite checkout origin/main`) e si rilanciano i test della visione. La regola vale ora per `origin/main` di TieVision-Core. Pin attuale: 4c178cf.
 
 Il worker gira in un container separato (`Dockerfile.vision`), non pubblica porte verso l'esterno ed è raggiungibile solo dal server all'indirizzo interno `http://vision:8100`. Il container non ha accesso al repository Git del progetto principale, quindi il commit di VisionSuite in uso (`engine_version`) non può essere scoperto dentro l'immagine: va stampato al momento del build leggendo il commit dalla macchina che esegue `docker compose build`, con la variabile `VISION_ENGINE_VERSION`. Una build senza questa variabile fallisce subito, invece di produrre un worker che risponde con una versione indovinata:
 

scripts/camera_service.py

@@ -2,7 +2,7 @@
 
 Cosa fa: espone via HTTP l'acquisizione di una camera (vs-camera: GigE/GenTL,
 OpenCV, cartella di immagini) con lo stesso contratto di `vs-gui`, ma solo
-`grab` (copiato da vendor/visionsuite/packages/vs-gui/.../server.py):
+`grab` (copiato da TieVision-Studio, src/visionsuite/gui/server.py):
   GET  /camera/sources   -> {"sources": [{name, kind, label}]}
   POST /camera/grab      json {source, trigger="continuo", timeout_ms=5000} -> PNG
 Errori: 400 parametri, 404 sorgente inesistente, 503 guasto camera, 504 timeout.