Record what a real sliced project did, and widen the start guard

A second live run, this time against a project the owner sliced in Bambu
Studio rather than a file already on the card, and through
`start_uploaded_file` itself rather than a hand-built body - so the
root-vs-cache fix is confirmed end to end. `gcode_file` in the printer's own
status came back as `cube-test-2026-10-11.gcode.3mf`, 150 layers, print_type
`local`.

It also found a defect the first run could not. The print heated to 250C,
reached 1%, and then the printer paused itself: `print_error: 50364420`
(`0x03008004`), `hms: []`, `tray_now: 255`. 255 is the external spool, which
is exactly what the hardcoded `use_ams: false` selects - so that pair
overrode the slicer's own filament choice and pointed an AMS-sliced project
at an external spool. The first run looked fine only because it was stopped
during PREPARE, before filament mattered. The doc comment said that pair was
"accepted, and the print ran"; it now says what it actually does, because
silently changing which filament a print uses is worse than not supporting
AMS at all.

The `start` guard demanded IDLE, which meant the harness refused every print
following a cancelled one - a Bambu reports an operator cancellation as
FAILED. IDLE, FINISH and FAILED are all terminal; PREPARE, RUNNING, PAUSE and
SLICING mean the machine is committed, and anything unrecognised is still
refused rather than assumed idle.

`bambu_cache_list` now prints nozzle/bed temperatures and remaining time.
State plus layer number cannot tell a print that is working from one that is
stalled: a P1P sits at layer 0 for minutes during bed levelling and purge,
and the only thing moving in that window is the heat.

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

src/printer/bambu.rs

@@ -670,11 +670,22 @@ impl BambuPrinter {
     /// - **`url` spelling.** `ftp:///<name>` - empty host, triple slash,
     ///   resolved against the card's root - is accepted. `file:///` was
     ///   never needed and remains untested.
-    /// - **`use_ams: false` / `ams_mapping: ""`.** Accepted, and the print
-    ///   ran. Note the limit of that evidence: the print was stopped during
-    ///   `PREPARE`/early `RUNNING`, so the pair was accepted but filament
-    ///   was never actually drawn. Real AMS support still means filling
-    ///   both fields together, not flipping the flag.
+    /// - **`use_ams: false` / `ams_mapping: ""`.** Accepted by the printer -
+    ///   and *wrong* on an AMS-equipped machine. Confirmed on a second run
+    ///   the same day, against a project the owner had sliced in Bambu
+    ///   Studio: the print started, heated to 250C, reached 1% and then the
+    ///   printer **paused itself** with `print_error: 50364420`
+    ///   (`0x03008004`), `hms: []`, `tray_now: 255`. 255 is the external
+    ///   spool, which is what `use_ams: false` selects - so this hardcoded
+    ///   pair overrode the slicer's own filament choice and pointed a
+    ///   project sliced for the AMS at an external spool instead.
+    ///
+    ///   So this is not merely "the only case wired up", as this comment
+    ///   used to say: it silently changes which filament a print uses.
+    ///   Until it is a real parameter, `start_uploaded_file` can only be
+    ///   trusted for projects that genuinely print from the external spool.
+    ///   Fixing it means reading the plate's filament mapping out of the
+    ///   `.3mf` and filling `use_ams` and `ams_mapping` together.
     ///
     /// Still a guess: **`param` is hardcoded to `Metadata/plate_1.gcode`**,
     /// i.e. always the first plate. Correct for the single-plate slice this