feat(docker): aggiungi flusso di sviluppo con hot reload via compose

Dockerfile diventa multi-stage con target `dev` (Vite + bind-mount) oltre
a `builder`/`runtime`; docker-compose.dev.yml lo usa per un ambiente di
sviluppo containerizzato equivalente a `npm run dev`, senza toccare il
compose di produzione (che resta pull-only dal registry). Documentato in
README e CLAUDE.md.

CLAUDE.md

@@ -84,12 +84,22 @@ Copertura statement/linee Vitest oltre il 99%. Per testare `startServer()` (`ser
 
 ## Deploy
 
-Docker, immagine pubblicata sul registry Gitea self-hosted (`santantonio.sytes.net`):
+`Dockerfile` è multi-stage con 4 target: `deps` (dipendenze condivise), `dev` (hot reload Vite), `builder` (build frontend), `runtime` (immagine di produzione, target di default).
+
+**Produzione** — `docker-compose.yml` usa l'immagine già pubblicata sul registry Gitea self-hosted (`santantonio.sytes.net`), niente build locale:
 
 ```bash
 docker compose up -d   # Avvia con immagine dal registry privato (porta 3000)
 ```
 
+**Sviluppo** — `docker-compose.dev.yml` builda il target `dev` in locale e monta il codice sorgente per l'hot reload (Vite su porta 5173); `node_modules` resta un volume anonimo del container per non farsi sovrascrivere dal bind-mount (evita anche problemi di binari nativi arch-specific tra host e container):
+
+```bash
+docker compose -f docker-compose.dev.yml up --build
+```
+
+Per buildare in locale l'immagine di produzione (es. per testarla prima del push sul registry): `docker build -t segnapunti:local .` (usa il target `runtime` di default).
+
 Volume `./.segnapunti` persiste lo stato tra i riavvii del container.
 
 ## Istruzioni operative