Add print.rs (AmsState/AmsUnit/AmsTray/XcamSettings), fix print vs pushing

Mirrors continuum-schemas' schemas/bambulab/ restructuring: PushallResponse
removed (it never existed on the wire — pushall's request goes to
"pushing", but the state-push stream it triggers arrives under "print",
a different root key, not a direct reply). BambuReport::Pushing(...) ->
BambuReport::Print(PrintReport).

AmsTray is an untagged enum (Empty/Loaded) rather than one struct full of
Option<T> fields, matching the JSON Schema's oneOf for the same slot -
#[serde(deny_unknown_fields)] on EmptyTray is load-bearing: untagged enums
try variants in order, and a loaded tray (superset of Empty's one field)
would otherwise incorrectly match Empty first.

Verified against the full real ams/xcam example from the conversation via
examples/bambu_commands_demo.rs - both the empty and loaded tray in that
payload deserialize to the correct enum variant.

src/printer/bambu_commands/mod.rs

@@ -7,15 +7,26 @@
 //! continuum-schemas for continuum.v1, which is a schema we designed
 //! ourselves and that both TS and Rust genuinely need.
 //!
-//! One file per command (`get_version.rs`, `pushall.rs`, ...) — each holds
-//! its request AND response together, since they're conceptually one unit.
-//! Copy `get_version.rs`'s shape for your next command.
+//! One file per Bambu *category* (`get_version.rs` for "info", `pushall.rs`
+//! + `print.rs` for "pushing"/"print" — see below for why those are two
+//! files, not one). Copy `get_version.rs`'s shape for your next command.
+//!
+//! Mirrors continuum-schemas' `schemas/bambulab/` JSON Schemas — same
+//! category split, same "print vs pushing" correction (see that
+//! directory's README for the full explanation): a `pushall` *request*
+//! goes to the "pushing" key, but the ongoing state-push stream it
+//! triggers arrives under a different key, "print" — so `PushallRequest`
+//! lives in `pushall.rs` and the thing it triggers, `PrintReport`, gets
+//! its own file, `print.rs`, rather than living together as if one were
+//! simply "the response to" the other.
 
 mod get_version;
+mod print;
 mod pushall;
 
 pub use get_version::{GetVersionRequest, GetVersionResponse, ModuleInfo};
-pub use pushall::{PushallRequest, PushallResponse};
+pub use print::{AmsState, AmsTray, AmsUnit, EmptyTray, LoadedTray, PrintReport, XcamSettings};
+pub use pushall::PushallRequest;
 
 /// Fields every Bambu command/response shares. This is the "inheritance"
 /// replacement for these structs — composition, not extension: every
@@ -34,12 +45,10 @@ pub struct CommandEnvelope {
 /// One request you can send to a Bambu printer, keyed by Bambu's top-level
 /// JSON category ("info", "pushing", ...). NOTE: that top-level key is a
 /// *category*, not the specific command — `CommandEnvelope::command` is
-/// what actually says which one ("get_version", "pushall", ...). Right
-/// now each category maps to exactly one known command, one-to-one. If a
-/// category ever needs a second command (e.g. "info" gaining something
-/// besides get_version), that variant's payload becomes its own small
-/// `#[serde(tag = "command")]` enum instead of a single struct — ask if
-/// you get there and want a worked example.
+/// what actually says which one ("get_version", "pushall", ...). A
+/// category can have more than one possible request shape — if that ever
+/// happens here, that variant's payload becomes its own small
+/// `#[serde(tag = "command")]` enum instead of a single struct.
 #[derive(serde::Serialize, Debug)]
 #[serde(rename_all = "snake_case")]
 pub enum BambuRequest {
@@ -47,10 +56,11 @@ pub enum BambuRequest {
     Pushing(PushallRequest),
 }
 
-/// Same idea, the response direction.
+/// Same idea, the response direction — note "print", not "pushing" (see
+/// this module's doc comment).
 #[derive(serde::Deserialize, Debug)]
 #[serde(rename_all = "snake_case")]
 pub enum BambuReport {
     Info(GetVersionResponse),
-    Pushing(PushallResponse),
+    Print(PrintReport),
 }