feat(production): la misura torna a cercare l'operatore

Il conto alla rovescia non si ferma piu' a zero. Oltre la scadenza continua
nell'altro senso e dice da quanto la linea e' in ritardo, in rosso, su tutte le
schermate del percorso di misura: lista task, riepilogo, scelta ricetta. Un
ritardo va letto, non dedotto. Allo scadere dell'intervallo la misura si
ripropone da sola: cicalino, un avviso di cinque secondi, e l'operatore torna al
primo task di misura da qualunque schermata si trovi.

Un ciclo copre tutti i task di misura della ricetta, quindi solo l'ultimo lo
chiude e fa ripartire l'intervallo. Farlo ripartire al primo avrebbe fatto
misurare una ricetta con tre task di misura tre volte piu' spesso di come e'
configurata. E' il server a decidere quale task chiude il ciclo, perche' e' lui
a conoscere la sequenza: la lista dei task di misura viaggia con la produzione
(measurement_task_ids), che e' anche cio' che permette a una schermata qualsiasi
di sapere dove riportare l'operatore.

Aggiunta la rimisura: si gira il pezzo e si misura di nuovo dentro lo stesso
ciclo, senza chiudere niente e senza guadagnare tempo sulla scadenza. Le due
letture restano entrambe in statistica, che e' il motivo per cui si prendono.

Chi sta gia' misurando quando l'intervallo scade e' in ritardo, non perso: la
banda diventa rossa e lo si lascia lavorare. Portarlo altrove a meta' ciclo
cancellerebbe quote che ha davanti agli occhi senza guadagnare nulla.

Sistemato anche il pulsante "Conferma ciclo" dell'overlay: alzava una bandierina
locale e basta, quindi il ciclo non veniva mai registrato sul server da quella
strada. Ora passa da confirmCycle come il pulsante della barra.

Migrazione 008: il registro eventi della produzione impara task_measured e
remeasure, e la colonna task_id — un task_measured che non dice quale task non
registra niente di utile. I valori nuovi entrano tutti insieme perche' allargare
una enum MySQL riscrive la tabella, stesso ragionamento dei tipi di task in 007.
Verificata su SQLite (batch mode) e in MySQL con --sql.

La logica dell'orologio — come si legge un ritardo, quando suona, dove sta la
misura — vive in un solo posto (production-clock.js) e la schermata di misura la
usa invece di riscriverla.

Test: +10 (265). Coprono il ciclo che non riparte a meta', la rimisura che non
sposta la scadenza, il rifiuto a linea ferma, la sequenza dei task di misura
esposta dalla produzione, i proxy Flask e la validita' JS della lista task.

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

src/backend/services/production_service.py

@@ -24,6 +24,7 @@ from src.backend.models.api.production import ProductionRunCreate
 from src.backend.models.orm.production import ProductionEvent, ProductionRun
 from src.backend.models.orm.recipe import Recipe, RecipeVersion
 from src.backend.models.orm.station import Station
+from src.backend.models.orm.task import MEASURING_TASK_TYPES, RecipeTask
 from src.backend.models.orm.user import User
 from src.backend.services import auth_service, production_export_service
 
@@ -103,6 +104,28 @@ async def get_station_by_code(db: AsyncSession, code: str) -> Station:
     return station
 
 
+async def measurement_task_ids(db: AsyncSession, version_id: int) -> list[int]:
+    """Ids of the measurement tasks of a version, in the order they are executed.
+
+    This is the loop the operator lives in once production starts: the client uses
+    the first of these to bring the measurement back on screen when the interval
+    expires, and the last to know which task closes a cycle.
+
+    The type is read from the declared task_type (point 2), not from whether quotes
+    happen to be present: a measurement task with no quotes yet is still where the
+    operator has to be taken.
+    """
+    result = await db.execute(
+        select(RecipeTask.id)
+        .where(
+            RecipeTask.version_id == version_id,
+            RecipeTask.task_type.in_(MEASURING_TASK_TYPES),
+        )
+        .order_by(RecipeTask.order_index, RecipeTask.id)
+    )
+    return list(result.scalars().all())
+
+
 async def list_run_events(db: AsyncSession, run_id: int) -> list[ProductionEvent]:
     result = await db.execute(
         select(ProductionEvent)
@@ -149,6 +172,7 @@ def _add_event(
     user: User,
     supervisor: Optional[User] = None,
     note: Optional[str] = None,
+    task_id: Optional[int] = None,
 ) -> ProductionEvent:
     """Append to the run's trace.
 
@@ -161,6 +185,7 @@ def _add_event(
         user_id=user.id,
         supervisor_id=supervisor.id if supervisor else None,
         note=note,
+        task_id=task_id,
         created_at=_now(),
     )
     db.add(event)
@@ -254,10 +279,7 @@ def _require_open(run: ProductionRun) -> None:
         )
 
 
-async def complete_cycle(
-    db: AsyncSession, run: ProductionRun, user: User, note: Optional[str] = None,
-) -> ProductionRun:
-    """Record a finished measurement cycle and restart the interval."""
+def _require_measurable(run: ProductionRun) -> None:
     _require_open(run)
     if run.status == "paused":
         raise HTTPException(
@@ -265,6 +287,36 @@ async def complete_cycle(
             detail="Production run is paused: resume it before measuring",
         )
 
+
+async def complete_cycle(
+    db: AsyncSession,
+    run: ProductionRun,
+    user: User,
+    task_id: Optional[int] = None,
+    note: Optional[str] = None,
+) -> ProductionRun:
+    """Record a finished measurement task, and restart the interval if it was the last.
+
+    A cycle spans every measurement task of the recipe, so only the last one closes
+    it. Restarting the interval at the first would make a recipe with three
+    measurement tasks measure three times as often as it was set up to.
+
+    An unrecognised task_id - or none at all - closes the cycle: a caller that does
+    not know about the sequence gets the behaviour that existed before it.
+    """
+    _require_measurable(run)
+
+    measure_ids = await measurement_task_ids(db, run.version_id)
+    closes_cycle = (
+        task_id is None or task_id not in measure_ids or task_id == measure_ids[-1]
+    )
+
+    if not closes_cycle:
+        _add_event(db, run, "task_measured", user, note=note, task_id=task_id)
+        await db.flush()
+        await db.refresh(run)
+        return run
+
     now = _now()
     run.cycle_count += 1
     if run.measurement_interval_minutes and run.measurement_interval_minutes > 0:
@@ -273,7 +325,29 @@ async def complete_cycle(
         run.next_measurement_at = now + timedelta(
             minutes=run.measurement_interval_minutes
         )
-    _add_event(db, run, "cycle_completed", user, note=note)
+    _add_event(db, run, "cycle_completed", user, note=note, task_id=task_id)
+    await db.flush()
+    await db.refresh(run)
+    return run
+
+
+async def remeasure(
+    db: AsyncSession,
+    run: ProductionRun,
+    user: User,
+    task_id: Optional[int] = None,
+    note: Optional[str] = None,
+) -> ProductionRun:
+    """Measure the same task again without closing the cycle.
+
+    This is the piece being turned over. The deadline and the cycle count are left
+    exactly as they are - a second reading of the same part is not a new cycle, and
+    it must not buy the operator another interval's worth of time. The values
+    themselves are ordinary measurements: both readings stay in the statistics,
+    which is the point of taking them.
+    """
+    _require_measurable(run)
+    _add_event(db, run, "remeasure", user, note=note, task_id=task_id)
     await db.flush()
     await db.refresh(run)
     return run