feat(production): dai una vita propria alla produzione, lato server

Punto 1 del documento modifiche del 28/07, il prerequisito su cui poggiano i
punti 3, 4 e 6.

Lo stato di una produzione viveva dentro una pagina del browser: timer, conteggio
cicli e flag "produzione avviata" erano variabili Alpine di task_execute.html, e
la navigazione fra task e' un ricaricamento completo, quindi cambiando task si
perdeva tutto. Da qui il loop di misura che non reggeva, il fermo linea che non
aveva nulla da fermare e l'assenza di storico.

Nuove tabelle production_runs e production_events (migrazione 005), endpoint REST
senza stato in memoria di processo - con un'app di stazione installata su ogni PC
il database e' l'unico posto condiviso - e il frontend che legge lo stato
all'apertura invece di tenerlo in memoria.

Tre scelte di modello:

- la scadenza e' un timestamp assoluto (next_measurement_at), non un contatore:
  il countdown si ricalcola da li' a ogni caricamento, e lasciarne andare la
  differenza sotto zero dara' gratis il contatore del ritardo del punto 3. Al
  client vanno i secondi gia' calcolati, non il timestamp: un datetime naive
  verrebbe letto nel fuso del browser e il conto sarebbe sfasato dell'offset UTC;
- l'intervallo di misura e' copiato sulla produzione, non referenziato: modificare
  la ricetta a produzione avviata non deve spostare una scadenza in corso;
- active_station_id rispecchia la stazione finche' la produzione e' aperta e va a
  NULL alla chiusura. Con un vincolo unico sopra, "una stazione = una produzione
  aperta" e' una garanzia del database e non un controllo soggetto a race; i NULL
  non collidono, quindi le produzioni chiuse si accumulano senza disturbo.

Il fermo linea congela il conto alla rovescia e alla ripresa la scadenza viene
traslata della durata del fermo, non ricalcolata: un fermo non regala ne' toglie
tempo all'operatore. L'autorizzazione del capoturno passa da authenticate_user e
non da un login, che rigenererebbe la sua API key buttando giu' la sessione che ha
aperta altrove.

La migrazione e' stata eseguita davvero, non solo scritta, su uno SQLite usa e
getta: upgrade e downgrade girano e le colonne coincidono con i modelli. La prova
ha trovato un difetto - create_unique_constraint dopo create_table e' un ALTER,
che SQLite rifiuta - ora il vincolo e' dichiarato dentro create_table.

Fuori da questo commit, per stare nei confini del punto 1: l'API espone gia'
pause, resume e close, ma i pulsanti fermo linea e fine produzione restano da
collegare (punto 6), e il rientro forzato sulla misura allo scadere e' il punto 3.

Corretti due difetti trovati strada facendo: env.py non importava ne' Station ne'
ProductionRun, quindi l'autogenerate di Alembic era gia' cieco sulle stazioni; e
task_execute.html, lo schermo con piu' JavaScript dell'applicazione, non era
coperto dal test di sintassi. Aggiungerlo ha richiesto di correggere l'helper, che
validava le espressioni Alpine solo come espressione singola e bocciava
@click="a = false; b = true", forma che Alpine accetta: ora prova entrambe le
letture e fallisce solo se cadono tutte e due.

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

src/backend/models/api/production.py

@@ -0,0 +1,71 @@
+"""Pydantic schemas for production runs and their events."""
+from datetime import datetime
+from typing import Literal, Optional
+
+from pydantic import BaseModel, ConfigDict, Field
+
+
+class ProductionRunCreate(BaseModel):
+    station_code: str = Field(..., min_length=1, max_length=100)
+    recipe_id: int = Field(..., gt=0)
+    version_id: Optional[int] = Field(default=None, gt=0)
+    lot_number: Optional[str] = Field(default=None, max_length=100)
+    serial_number: Optional[str] = Field(default=None, max_length=100)
+
+
+class ProductionEventResponse(BaseModel):
+    model_config = ConfigDict(from_attributes=True)
+    id: int
+    event_type: str
+    user_id: int
+    supervisor_id: Optional[int]
+    note: Optional[str]
+    created_at: datetime
+
+
+class ProductionRunResponse(BaseModel):
+    model_config = ConfigDict(from_attributes=True)
+
+    id: int
+    station_id: int
+    recipe_id: int
+    version_id: int
+    operator_id: int
+    lot_number: Optional[str]
+    serial_number: Optional[str]
+    status: str
+    measurement_interval_minutes: Optional[int]
+    next_measurement_at: Optional[datetime]
+    cycle_count: int
+    started_at: datetime
+    paused_at: Optional[datetime]
+    closed_at: Optional[datetime]
+    closed_by: Optional[int]
+
+    # Derived server-side so every client agrees on the countdown regardless of
+    # clock skew. Negative once the interval has elapsed: how long the run has been
+    # overdue is a fact the operator must see, not deduce.
+    seconds_to_next_measurement: Optional[int] = None
+    overdue: bool = False
+    server_time: Optional[datetime] = None
+
+
+class ProductionRunWithEventsResponse(ProductionRunResponse):
+    events: list[ProductionEventResponse] = Field(default_factory=list)
+
+
+class SupervisorAction(BaseModel):
+    """Credentials of the supervisor authorising a line stop or a close."""
+
+    supervisor_username: str = Field(..., min_length=1)
+    supervisor_password: str = Field(..., min_length=1)
+    note: Optional[str] = None
+
+
+class CycleCompletePayload(BaseModel):
+    note: Optional[str] = None
+
+
+ProductionEventType = Literal[
+    "start", "cycle_completed", "line_stop", "resume", "close",
+]