Confirm the light and the upload on a real P1P

Four things were shipped unverified because the printer was off when they
were written. Three are now confirmed first-hand (P1P, 2026-10-15), and one
is settled in the opposite direction from what was assumed.

**`set_light` had never once reached a printer**, and `completion::run`
blinks a finished print's chamber light with it. It works - but "accepted" is
not "it changed": `ledctrl` answers `result: "success"` as soon as the
command parses, exactly like the print-control verbs. So `lights_report` is
now modelled on `PrintReport`, which is the only read-back there is, and the
probe polls it rather than printing a reassuring message. Setting the light
on and off reads `[{"node":"chamber_light","mode":"on"}]` / `"off"` back,
about 3s later. The field was observed on v1 even though only the v2 schema
declares it.

**The blink itself works at the rate it ships at.** `completion::celebrate`
is now public so the probe runs the real function instead of a copy: twenty
`ledctrl` commands half a second apart, which a printer is entitled to
refuse. None were refused, it returned after 10.35s, and the light ended
`off` as specified - a blink that leaves the light on would look like a
printer still working.

**The firmware's own `flashing` mode is not the better option.** It is
accepted, and the reply echoes all four parameters back
(`led_on_time`, `led_off_time`, `loop_times`, `interval_time`), so the
printer does parse them. But `lights_report` never reports `flashing` - it
stayed on the previous mode for 12s of polling. A firmware blink is therefore
unobservable: nothing can confirm it happened or tell when it ended, while
the self-driven blink is built from a call that reads back. That is a better
reason to keep `celebrate` than the one in the comment it replaces, which was
that `loop_times` semantics were unconfirmed. Whether the light physically
blinks is still unwitnessed - nobody was watching the machine.

**Multi-MB FTPS upload works, and is slow.** A 4.96 MB project archive went
up with an exact byte count and came back byte-identical (sha256). But it
took 31.3s - about 0.2 MiB/s - so the 62 MB project already on that card
would take six and a half minutes. Anything that uploads a job needs a
timeout budgeted in minutes, not seconds. The claim in `download`'s comment
that these files are "a few hundred KB" is gone; the card disproves it.

Also adds `delete`, because the probe left a 5 MB file on a real SD card and
there was no way to remove it. One explicit path, no globbing: the convenient
version of this deletes something somebody printed from last week. Used to
clean up, and the card is back as it was.

New probe steps: `light on|off|flash`, `blink`, `upload <local> [name]`,
`delete <path>`. 51 tests still pass.

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

src/printer/bambu.rs

@@ -933,6 +933,31 @@ impl BambuPrinter {
         .map_err(|err| PrinterError(format!("{}: FTPS download failed: {err}", self.base.name)))
     }
 
+    /// Removes one file from the printer's SD card.
+    ///
+    /// Takes one explicit path, because the convenient version of this is
+    /// also the dangerous one - see `bambu_ftps::delete`. Nothing calls it
+    /// automatically yet: a gateway that uploads a project per job needs to
+    /// clear them eventually, but *which* file is safe to remove is a
+    /// question about the job queue, not about FTPS.
+    pub async fn delete_file(&self, path: &str) -> Result<(), PrinterError> {
+        let connector = self
+            .tls
+            .build_connector()
+            .map_err(|err| PrinterError(format!("{}: TLS setup failed: {err}", self.base.name)))?;
+
+        let host = self.base.host.clone();
+        let access_code = self.access_code.clone();
+        let path = path.to_string();
+
+        tokio::task::spawn_blocking(move || {
+            super::bambu_ftps::delete(&host, &access_code, connector, &path)
+        })
+        .await
+        .map_err(|err| PrinterError(format!("{}: FTPS delete thread failed: {err}", self.base.name)))?
+        .map_err(|err| PrinterError(format!("{}: FTPS delete failed: {err}", self.base.name)))
+    }
+
     /// `list_cache` for any directory on the printer's SD card.
     ///
     /// Read-only, and the way to answer "what is the path to this file?"