feat(tech-steps): detecte les temperatures dans les etapes

3e type de metadonnee de clause, a cote des ingredients et des ustensiles :
temperature en °C (« 180°C », « 200 degres », °F converti), numero de
thermostat (« th. 6 ») et intensite qualitative (« feu doux/moyen/vif » ->
low/medium/high).

services/tech-step-intent-service :
- `temperature_extraction.py` : `extract_temperatures(text, locale)` pur,
  a base de regex (independant du modele spaCy et de l'entrainement).
- `ProcessResult` / `ProcessResponse` gagnent `temperatures` (ajout additif
  au contrat ; cle `gas_mark` en snake_case sur le fil). `process()` les
  extrait meme pour une locale pas encore entrainee.
- Tests `test_temperature_extraction.py` (10) ; `test_routes_process.py` :
  2 assertions d'egalite stricte gagnent `"temperatures": []`, +1 cas.

apps/api :
- `IntentServiceTemperature` (mappe `gas_mark` -> `gasMark` a la frontiere).
- `TechStepMatch.temperatures` : filtrees par appartenance de span a la
  clause, meme regle que les ustensiles.
- `model StepTechStepTemperature` (aucune FK — la valeur structuree EST la
  donnee) + migration manuelle `20260829120000_step_tech_step_temperature`
  (cascade via le TRUNCATE de `step_tech_step`, rien a ajouter a
  reset-db.ts). Persistance + lecture dans `recipe.service.ts`
  (`recipeInclude`, `toStepTechStepViews`) et l'include de sequence fraiche
  du service de correction ; `sources.service.ts` (apercu d'import) les
  fait transiter.

packages/shared : `StepTechStepTemperatureView` + `temperatures` sur
`StepTechStepView`.

apps/web :
- `splitDescriptionSegments` enrobe `splitDescriptionByTechSteps` et
  redecoupe les segments non-keyword autour des spans de temperature (la
  logique technique intriquee reste intacte). `?? []` tolere une payload
  d'avant `temperatures`.
- `StepDescription` : surlignage `.step-temperature` + Tooltip via
  `temperatureLabel` ; i18n `recipes.temperature.*`.
- Tests composants +4 (22 verts) ; pas d'UI de correction (v1, comme les
  ustensiles).

Verifie : biome + tsc + `pnpm -r build` ; web 102/103 e2e (l'echec est le
flake pre-existant recipe-form.feature, sans rapport) + 49/49 composants ;
pytest temperature + routes 15/15. `pnpm --filter api test` (Postgres +
intent-service requis) non lance ici.

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

apps/web/cypress/e2e/admin-monitoring.cy.ts

@@ -52,19 +52,8 @@ describe("Admin monitoring", () => {
     cy.intercept("GET", "**/admin/auth/me", { statusCode: 200, body: adminBody });
   });
 
-  // The page route `/admin/monitoring` and the API path `GET /admin/monitoring`
-  // are identical — a plain `**/admin/monitoring` glob would also match the
-  // `cy.visit()` document request (and whether that's same-origin or not
-  // depends on `VITE_API_URL`, which isn't set in CI). `resourceType: "fetch"`
-  // pins the intercept to the `AdminApiClient` XHR only.
-  const monitoringApi = {
-    method: "GET",
-    url: "**/admin/monitoring",
-    resourceType: "fetch",
-  } as const;
-
   it("renders one card per service with its status and details", () => {
-    cy.intercept(monitoringApi, {
+    cy.intercept("GET", "http://localhost:3000/admin/monitoring", {
       statusCode: 200,
       body: monitoringFixture(),
     }).as("getMonitoring");
@@ -85,7 +74,7 @@ describe("Admin monitoring", () => {
   });
 
   it("shows an error state when the request fails", () => {
-    cy.intercept(monitoringApi, {
+    cy.intercept("GET", "http://localhost:3000/admin/monitoring", {
       statusCode: 500,
       body: { code: 5000, message: "x" },
     });