Fix print.push_status parsing, and stop losing reports silently

Pointed at a real H2C that was 20% into a job, `print_status()` returned
nothing at all. The printer was in fact pushing a full status object every
second; every one was arriving, failing to deserialize, and being dropped
invisibly by an `if let Ok(report) = ..` with no `else`.

That silence produced two confidently-wrong claims in our own comments,
both corrected here:

- `pushall`'s doc said whether v2 emits `push_status` unprompted was "an
  open question". It is not: v2 pushes a full 97-field object roughly once
  a second from the moment you subscribe, no trigger needed. There is no
  missing "other trigger" to hunt for.
- The "sequence gap" warning blamed the network for dropped v1 updates.
  Those updates were not dropped in transit - they failed to parse, so
  they never reached the counter, making the next one that did look like a
  skip. Confirmed: seq 57, 62, 64 and 69 all arrived. After the fix, zero
  gaps and zero parse failures across a 25s run against both printers.

Two concrete causes, both found with captured payloads:

- v1 trays carry `tray_temp`/`tray_time`; v2 trays carry
  `drying_temp`/`drying_time`. All four were required, so *every* v1 push
  carrying AMS data failed.
- A third tray shape existed that nothing modelled: an empty v2 slot sends
  `{"id": "2", "state": 0}`, which matched neither `EmptyTray` (it denies
  unknown fields, deliberately) nor `LoadedTray` (16 fields short).

A parse failure now reports itself, naming the printer, the sequence id and
the serde error. A report this process cannot parse is a defect in
`PrintReport`, and the only way to fix it is to be told which field.

`PrintReport` itself modelled 9 of 97 top-level fields, and none of them
were progress or temperature - it was built from a truncated example. It
now carries gcode_state, percent, layer counts, remaining time, nozzle/bed
temperatures, fan gears, wifi and HMS entries. `merge_from`'s two dozen
four-line blocks collapse to `newer.x.or(self.x.take())` one-liners: the
old shape made adding a field a three-place edit, and forgetting the merge
half produced a field that silently never survived a partial update.

Two scale traps documented where they bite: reported fan speeds are 0-15
gears, not percent and not the 0-255 PWM we send (`set_fan_speed(50)`
reads back as "7"); and v2 pins `sequence_id` to one value for minutes
while contents change, so it orders and identifies nothing there.

Two examples, and the distinction between them is the point. `live_reports`
is read-only and safe against a printer mid-job. `bambu_idle_checks`
writes, so it requires an explicit printer id and refuses to run unless
that printer reports `gcode_state: "IDLE"`.

Regression fixtures are verbatim captures off both printers, hardware
identifiers scrubbed - the only way to keep this from regressing without a
printer plugged in.

README.md

@@ -29,6 +29,31 @@ cloud control plane (`continuum-backend`).
   (`src/uplink/`).
 - **go2rtc watchdog** - restarts the camera-restreaming subprocess if it
   dies (`src/go2rtc.rs`).
+- **Bambu file upload** - implicit FTPS (port 990) into the printer's own
+  `cache/` directory (`src/printer/bambu_ftps.rs`, via
+  `BambuPrinter::upload_file`). **Confirmed live against a P1P on
+  2026-10-03**: login, binary mode, and the transfer all work, byte count
+  matched exactly.
+- **Print status** - `print.push_status` parsed into `PrintReport` with real
+  job progress, temperatures, fans and HMS entries. Confirmed live on both
+  generations (idle P1P on v1, H2C 20% into a job on v2); regression
+  fixtures from those captures are in `tests/fixtures/`.
+
+## Examples worth knowing
+
+- `cargo run --example live_reports [printer-id]` - **read-only**, safe
+  against a printer that is mid-print. Connects, reports firmware, and
+  watches the status stream. Redirect stderr to capture raw payloads.
+- `cargo run --example bambu_idle_checks -- <printer-id>` - **writes**
+  (FTPS upload, fan speed). Requires an explicit printer id and refuses to
+  run unless that printer reports `gcode_state: "IDLE"`.
+
+## What's still a stub (cont.)
+
+`start_uploaded_file` - the MQTT command that actually *starts* a print from
+an uploaded file - is written but has deliberately never been fired, since
+that commits a machine to hours of work. Its doc comment lists the three
+details to confirm on the first real attempt.
 
 ## What's still a stub