Confirm the print path on a real P1P, and stop discarding its answer

Print control (pause/resume/stop) and print start are now both confirmed
against the P1P on the LAN, and doing that turned up three real defects.

`start_uploaded_file` published fire-and-forget, so the printer's reply was
thrown away. Asking it to print a file it does not have returned `Ok(())`,
and watching `print.push_status` could not tell that apart from a successful
start, since both leave the machine IDLE for a while. The printer does in
fact answer - `{"command":"gcode_file","param":"...","reason":"error
string","result":"fail"}` - and it echoes the `sequence_id` we send, so
`request` correlates it. Both this and `control_print` now go out as
correlated requests and run the reply through `print_command_outcome`.

The upload and the print command disagreed about where files live. `upload`
cwd'd into `cache/` while the printable projects are in the card's root: the
root holds 43 `<name>.gcode.3mf` archives, `cache/` holds the printer's own
extracted `<project>_plate_N.gcode` working copies with `.gcode.bbl`
sidecars. Those extracted copies are not independently printable -
`gcode_file` with `param: "/cache/Cube_plate_1.gcode"` was rejected for a
file the FTPS listing shows is right there - while `project_file` with
`url: "ftp:///Cube.gcode.3mf"` started a print. So the destination is now a
parameter and both halves point at `SD_ROOT`.

What the hardware settled, recorded in the doc comments: the `ftp:///` url
spelling is right, `param: "Metadata/plate_1.gcode"` works for a
single-plate project, `use_ams: false` + `ams_mapping: ""` is accepted, and
a stop during PREPARE/RUNNING moves the printer to FAILED, which is how
Bambu reports an operator cancellation. What it did not settle: all three
control verbs answer `result: "success"` on an *idle* printer, so the reply
means "accepted", not "the state changed" - callers still have to read
`gcode_state` back.

`PrinterCommand::ControlPrint` makes this reachable from the cloud at all;
until now pause/resume/stop existed in the proxy with no way to send them.
Still no start-print variant, now for a different reason: the path around it
is missing, not the hardware proof.

Also: `list_dir` for any directory (how the layout above was found, without
sending a print command to guess), `request_raw` for probing an unconfirmed
command shape, and two examples - `bambu_cache_list` (read-only) and
`bambu_print_probe` (gated steps, `start` needing both IDLE and
--yes-start-a-real-print).

tests/uplink_protocol.rs

@@ -12,6 +12,7 @@
 //! mirrors; the canonical shape is
 //! `continuum-schemas/schemas/continuum/v1/edge/`.
 
+use continuum_proxy::printer::PrintControl;
 use continuum_proxy::uplink::{ClientMessage, PrinterCommand, PrinterTelemetry, ServerMessage};
 
 /// Verbatim from the backend's `src/routes/ws/edge.ts`. If the backend
@@ -22,6 +23,9 @@ const BACKEND_MESSAGES: &[&str] = &[
     r#"{"type":"heartbeat_ack","seq":7}"#,
     r#"{"type":"command","command_id":"9a7d2f10-0000-4000-8000-000000000000","printer_id":"p1p","command":{"action":"set_fan_speed","percent":40}}"#,
     r#"{"type":"command","command_id":"9a7d2f11-0000-4000-8000-000000000000","printer_id":"p1p","command":{"action":"send_gcode_line","line":"M106 S0"}}"#,
+    r#"{"type":"command","command_id":"9a7d2f12-0000-4000-8000-000000000000","printer_id":"p1p","command":{"action":"control_print","control":"pause"}}"#,
+    r#"{"type":"command","command_id":"9a7d2f13-0000-4000-8000-000000000000","printer_id":"p1p","command":{"action":"control_print","control":"resume"}}"#,
+    r#"{"type":"command","command_id":"9a7d2f14-0000-4000-8000-000000000000","printer_id":"p1p","command":{"action":"control_print","control":"stop"}}"#,
 ];
 
 #[test]
@@ -50,15 +54,61 @@ fn a_command_arrives_with_its_payload_intact() {
     }
 }
 
-/// The variant that is deliberately absent. When this test starts failing
-/// because someone added it, that is the moment to check the print-start path
-/// has actually been run against real hardware first.
+/// Each control verb has to arrive as the right `PrintControl`, not merely
+/// parse. A silent mis-mapping here would send a stop where a pause was
+/// asked for, which on a real machine is the difference between a print that
+/// can be resumed and one that is over.
+#[test]
+fn each_print_control_verb_maps_to_its_own_action() {
+    for (verb, expected) in [
+        ("pause", PrintControl::Pause),
+        ("resume", PrintControl::Resume),
+        ("stop", PrintControl::Stop),
+    ] {
+        let raw = format!(
+            r#"{{"type":"command","command_id":"c","printer_id":"p1p","command":{{"action":"control_print","control":"{verb}"}}}}"#
+        );
+        match serde_json::from_str::<ServerMessage>(&raw).expect("should parse") {
+            ServerMessage::Command { command: PrinterCommand::ControlPrint { control }, .. } => {
+                assert_eq!(control, expected, "'{verb}' mapped to the wrong action");
+                // And the wire word the vendor layer sends has to match the
+                // wire word that arrived - `as_str` is what builds the Bambu
+                // command name.
+                assert_eq!(control.as_str(), verb);
+            }
+            other => panic!("wrong variant for '{verb}': {other:?}"),
+        }
+    }
+}
+
+/// "cancel" is the trap: it is Moonraker's word, and the Klipper
+/// implementation behind `control_print` really does send a cancel - but the
+/// wire word is "stop". A verb only one vendor recognises must be rejected
+/// here rather than reaching a gateway that cannot map it.
+#[test]
+fn a_vendor_specific_control_verb_is_rejected() {
+    for verb in ["cancel", "abort", "Pause", ""] {
+        let raw = format!(
+            r#"{{"type":"command","command_id":"c","printer_id":"p1p","command":{{"action":"control_print","control":"{verb}"}}}}"#
+        );
+        assert!(
+            serde_json::from_str::<ServerMessage>(&raw).is_err(),
+            "'{verb}' parsed as a print control verb and should not have"
+        );
+    }
+}
+
+/// The variant that is deliberately absent - still, but no longer for the
+/// original reason. The print-start path *has* now been confirmed on a real
+/// P1P (2026-10-11); what is missing is the path around it, since nothing
+/// uploads a sliced file to a gateway and nothing decides which printer runs
+/// which job. Delete this test when there is something to start.
 #[test]
 fn there_is_no_start_print_command() {
     let raw = r#"{"type":"command","command_id":"x","printer_id":"p1p","command":{"action":"start_print","file_name":"plate_1.3mf"}}"#;
     assert!(
         serde_json::from_str::<ServerMessage>(raw).is_err(),
-        "a start-print command parsed - has the hardware test been done?"
+        "a start-print command parsed - is there a job path to drive it yet?"
     );
 }