Add stage to printer telemetry

Bambu's `stg_cur`: what a printer is doing when it is not laying down
plastic - bed levelling, nozzle cleaning, extrusion calibration. Passed
through as the printer's own number rather than decoded, because the
code-to-name table is not something we have. 0 means printing.

It is here because progress without it is ambiguous in a way that reads as a
fault. Confirmed on a P1P (2026-10-11): `percent` climbed to 14% while
`layer` stayed 0 for several minutes, the printer working through stages 54,
14 and 13 before starting layer 1. A console showing 14% at layer 0 with no
stage looks stuck, and an operator would reasonably go and power-cycle a
machine that was working perfectly.

Optional and additive, so gateways that predate it are unaffected.

schemas/continuum/v1/edge/printer_telemetry.schema.json

@@ -28,6 +28,10 @@
       "maximum": 100,
       "description": "Readers must accept an explicit null here as equivalent to the key being absent: a gateway omits what it has no value for, but a serde-derived Rust producer emits null unless every field is annotated, and rejecting a whole batch over that is not worth it."
     },
+    "stage": {
+      "type": "integer",
+      "description": "The printer's current stage, when it is doing something other than laying down plastic: bed levelling, nozzle cleaning, extrusion calibration and so on. Bambu's `stg_cur`, passed through as the printer's own number rather than decoded, because the code-to-name table is not something we have. 0 means printing.\n\nWithout this, progress is ambiguous in a way that reads as a fault. Confirmed on a P1P (2026-10-11): `percent` climbed to 14% while `layer` stayed 0 for several minutes, because the printer was working through its pre-print stages - it reported `stg_cur` 54, then 14, then 13, then 0, and only then began layer 1. A console showing 14% at layer 0 with no stage looks stuck."
+    },
     "layer": {
       "type": [
         "integer",