feat(recipes): la ricetta decide cosa pretendere e come si misura

Tre cose che prima non erano di nessuno diventano regole della ricetta, decise da
chi la scrive e fatte valere dal server.

Punto 8 — tracciabilita' obbligatoria. Lotto e seriale si dichiarano obbligatori
sulla ricetta. L'operatore li inserisce alla selezione, dove il pulsante non si
attiva finche' mancano, e la stessa regola vale sulla lista task, raggiungibile
anche per link diretto, e sul barcode: uno sbarramento che dura solo finche'
qualcuno prende in mano il lettore non e' uno sbarramento. La produzione non si
apre e la misura non si salva senza cio' che la ricetta pretende, perche' un
valore senza il suo lotto non e' riconducibile a niente, e accorgersene dopo
significa accorgersene tardi.

Punto 9 — inserimento manuale. Una ricetta puo' vietare i valori digitati, ed e'
il valore predefinito: il calibro e' lo strumento, digitare e' cio' che va
concesso. Dove e' vietato il tastierino non viene disegnato (non nascosto con i
CSS: il markup nascosto e' markup che si puo' rimostrare) e restano correzione e
conferma, perche' una lettura sbagliata va cancellata. Il controllo vero e' sul
server: una regola che vive solo nel frontend e' un consiglio.

Migliorato al passaggio il riconoscimento del calibro. Contava solo la raffica di
cifre, cosi' una lettura corta come "9.5" — tre battute — finiva registrata come
digitata a mano; ora conta anche l'Invio che il wedge manda dentro la stessa
raffica. Senza questa correzione il divieto avrebbe respinto misure legittime.

Punto 11 — formattazione delle descrizioni. A capo e grassetto sopravvivono: chi
scrive le ricette incolla dal PDF della scheda tecnica e il testo arrivava
appiattito, da risistemare a mano ogni volta. Nessun HTML viene accettato o
salvato — il testo viene escapato e gli unici tag nel risultato sono quelli
prodotti dal renderer. La sanificazione e' questa: non c'e' niente da sanificare
perche' non si accetta niente. Le stesse due regole in Jinja e in JS, cosi' una
descrizione si legge uguale ovunque. E la descrizione ora si vede anche in
esecuzione: era scritta per l'operatore e la vedeva solo chi la scriveva.

Migrazione 009: tre colonne sulla ricetta. Le due di tracciabilita' partono
false, che e' il comportamento di oggi; l'inserimento manuale parte *vero* sulle
ricette gia' esistenti — il default della colonna e' falso, quindi le ricette
nuove sono solo-calibro, ma spegnerlo d'ufficio su quelle in uso fermerebbe una
linea alla misura successiva. Chi possiede la ricetta lo decide dall'editor.

Test: +26 (291). Coprono il rifiuto sul server per lotto, seriale e valore
digitato, il calibro sempre ammesso, le regole che sopravvivono alla nuova
versione, il tastierino assente in pagina, l'Avvia sbarrato, e il renderer delle
descrizioni compreso il caso in cui si prova a farci passare un tag.

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

src/frontend/flask_app/templates/maker/task_editor.html

@@ -292,8 +292,14 @@
         </div>
         <!-- Descrizione -->
         <div class="sm:col-span-2">
-          <label class="tmf-label">{{ _('Descrizione') }}</label>
+          <div class="flex items-center justify-between gap-2">
+            <label class="tmf-label">{{ _('Descrizione') }}</label>
+            {% with target = 'newTaskDescription' %}
+              {% include "components/rich_text_toolbar.html" %}
+            {% endwith %}
+          </div>
           <textarea x-model="newTask.description"
+                    x-ref="newTaskDescription"
                     class="tmf-input text-sm"
                     rows="3"
                     placeholder="{{ _('Descrizione opzionale...') }}"></textarea>
@@ -519,7 +525,10 @@
                 <template x-if="task.description">
                   <div class="flex items-start gap-2">
                     <span class="text-xs font-semibold text-[var(--text-muted)] uppercase tracking-wide shrink-0 mt-0.5">{{ _('Descrizione') }}:</span>
-                    <span class="text-sm text-[var(--text-secondary)] whitespace-pre-wrap" x-text="task.description"></span>
+                    {# Shown the way the operator will see it - the point of the
+                       formatting is that the maker can check it here. #}
+                    <span class="text-sm text-[var(--text-secondary)]"
+                          x-html="richText(task.description)"></span>
                   </div>
                 </template>
               </div>
@@ -544,8 +553,14 @@
                          placeholder="{{ _('Direttiva opzionale...') }}">
                 </div>
                 <div class="sm:col-span-2">
-                  <label class="tmf-label">{{ _('Descrizione') }}</label>
+                  <div class="flex items-center justify-between gap-2">
+                    <label class="tmf-label">{{ _('Descrizione') }}</label>
+                    {% with target = 'editTaskDescription' %}
+                      {% include "components/rich_text_toolbar.html" %}
+                    {% endwith %}
+                  </div>
                   <textarea x-model="editTaskData.description"
+                            x-ref="editTaskDescription"
                             class="tmf-input text-sm"
                             rows="3"
                             placeholder="{{ _('Descrizione opzionale...') }}"></textarea>
@@ -1076,6 +1091,8 @@
 {% endblock %}
 
 {% block extra_js %}
+{# Bold and line breaks in descriptions: the same rules the server renders with. #}
+<script src="{{ url_for('static', filename='js/rich-text.js') }}"></script>
 <script src="{{ url_for('static', filename='vendor/pdf-3.11.174.min.js') }}"></script>
 <script>if(typeof pdfjsLib!=='undefined')pdfjsLib.GlobalWorkerOptions.workerSrc='{{ url_for('static', filename='vendor/pdf.worker-3.11.174.min.js') }}';</script>
 <script src="{{ url_for('static', filename='js/annotation-viewer.js') }}?v=6"></script>