Drop proto/bambulab/ — plain hand-written Rust structs instead

Reconsidered after actually feeling the friction: this data is JSON over
MQTT (not binary protobuf), only continuum-proxy ever parses it (raw
vendor wire format, never crosses into TS), so none of protobuf's actual
value (cross-language codegen, binary wire efficiency) applied here.
Every gotcha hit while building this (field_attribute's oneof/variant
path collision, needing .bambulab-scoped type_attribute calls, explicit
#[serde(default)] per not-always-present field) came from forcing
prost-build's codegen model onto a plain-JSON, Rust-only use case.

Verified the replacement is strictly simpler, not just smaller: a
hand-written struct's Option<T> field needs zero extra attributes to
handle a missing JSON key (prost's generated String needed an explicit
field_attribute call per field), and #[serde(flatten)] on a hand-written
field has no ambiguity at all (prost-build's oneof/variant path collision
doesn't exist without prost-build's codegen in the picture).

The replacement lives in continuum-proxy: src/printer/bambu_commands/.
continuum.v1 is unaffected — that schema is genuinely cross-language and
proto still earns its keep there.

proto/bambulab/common.proto

@@ -1,9 +0,0 @@
-syntax = "proto3";
-
-package bambulab;
-
-// Fields/messages genuinely shared between v1 and v2 (unversioned, since
-// they don't change across generations) go here — composition, embedded as
-// a field in v1/v2 messages via `import "bambulab/common.proto";`, not
-// inheritance. e.g. every Bambu command/response shares sequence_id +
-// command; that's a good candidate for a message here.

proto/bambulab/v1/report.proto

@@ -1,15 +0,0 @@
-syntax = "proto3";
-
-package bambulab.v1;
-
-// import "bambulab/common.proto"; once common.proto has a shared message
-// worth embedding (composition, not inheritance — see that file).
-
-// Your report/response messages go here, e.g.:
-//
-// message InfoResponse {
-//   string sequence_id = 1;
-//   string command = 2;
-//   string result = 3;   // not always present — see build.rs field_attribute
-//   string reason = 4;   // not always present — see build.rs field_attribute
-// }

proto/bambulab/v1/request.proto

@@ -1,23 +0,0 @@
-syntax = "proto3";
-
-package bambulab.v1;
-
-// One real, fully-wired example — copy this shape for every other command
-// (pushing/pushall, print control, etc.). sequence_id is `string`, not
-// int64: Bambu sends it as a JSON string ("0"), and this crosses the wire
-// as JSON over MQTT, not binary protobuf — the Rust type needs to match
-// what serde_json actually produces, not what "feels more correct" for a
-// counter.
-message InfoCommand {
-  string sequence_id = 1;
-  string command = 2;
-}
-
-// Add your next message here, e.g.:
-//
-// message PushingCommand {
-//   string sequence_id = 1;
-//   string command = 2;
-//   int32 version = 3;
-//   int32 push_target = 4;
-// }

proto/bambulab/v2/report.proto

@@ -1,9 +0,0 @@
-syntax = "proto3";
-
-package bambulab.v2;
-
-// import "bambulab/common.proto"; once common.proto has a shared message
-// worth embedding (composition, not inheritance — see that file).
-
-// V2-generation (X1/H2 series) report/response messages go here — e.g.
-// whatever AMS/report-schema fields V2 has that V1 doesn't.

proto/bambulab/v2/request.proto

@@ -1,8 +0,0 @@
-syntax = "proto3";
-
-package bambulab.v2;
-
-// import "bambulab/common.proto"; once common.proto has a shared message
-// worth embedding (composition, not inheritance — see that file).
-
-// V2-generation (X1/H2 series) command messages go here.