Category subdirectories for request/report; ams/xcam split; print vs pushing fix

Each root JSON key ('info', 'pushing', 'print') now gets its own category
folder under request/ and report/, so a category can hold multiple command
schemas without flattening them into one directory - v1/request.schema.json
and v1/report.schema.json route into these via oneOf per category (also
future-proofs for a category ever needing more than one shape).

Split pushall's ams/xcam fields the same way module_info was already
split: ams.schema.json/ams_unit.schema.json/ams_tray.schema.json/
xcam.schema.json/print.schema.json, each referencing the next by relative
$ref. ams_tray.schema.json uses oneOf for the empty-vs-loaded tray shapes
- verified (and initially got wrong, then fixed) that LoadedTray needs
every field required, not just id, or a bare {"id":"0"} validates
against both branches and oneOf fails, since oneOf demands exactly one
match.

Real correction: the report/ category for what a pushall request
triggers is "print", not "pushing" - re-reading the original examples,
pushall's REQUEST goes to "pushing", but the resulting state-push stream
arrives under "print", a different root key. report/pushing/ (my
original mistake) is removed; report/print/ holds the corrected content.
request/pushing/ is untouched - that side was correct.

Also: v2/ removed (found as broken copy-pasted stubs still pointing at
v1 $ids - no real V2-specific content yet, better to have nothing than
broken duplicates); all $ids switched to real, verified Gitea raw-file
URLs (raw/branch/main/<path> - confirmed this is the correct pattern,
not raw/<path>) instead of a placeholder domain; fixed a broken relative
$ref in the request-side files left over from an earlier move (still
pointing 2 levels up instead of 3 after nesting one level deeper).

Re-validated everything against real examples after restructuring,
including the full ams/xcam print report and two negative cases -
see schemas/bambulab/README.md for the validation script.

schemas/bambulab/v1/report/print/print.schema.json

@@ -0,0 +1,17 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://git.octoturge.com/Continuum/continuum-schemas/raw/branch/main/schemas/bambulab/v1/report/print/print.schema.json",
+  "title": "PrintReport",
+  "description": "The ongoing print-state push (root key \"print\") — NOT a direct reply to the pushall request (that goes to \"pushing\", see request/pushing/pushall.schema.json). Sending pushall makes the printer start/refresh this stream; it isn't itself request/response, which is also why this is its own category folder rather than sitting under pushing/ — a category here is 'what root key does this arrive under', not 'what triggered it'. Doesn't extend envelope.schema.json: the example seen so far doesn't show sequence_id/command on this one, and it may genuinely not carry them (an async push, not a direct reply) — revisit if a real capture proves otherwise. The real payload has many more fields than shown here (this example was truncated) — add them under `properties` the same way you'd add them to bambu_commands/print.rs.",
+  "type": "object",
+  "properties": {
+    "ams": { "$ref": "ams.schema.json" },
+    "ams_exist_bits": { "type": "string" },
+    "insert_flag": { "type": "boolean" },
+    "power_on_flag": { "type": "boolean" },
+    "tray_exist_bits": { "type": "string" },
+    "tray_is_bbl_bits": { "type": "string" },
+    "xcam": { "$ref": "xcam.schema.json" },
+    "xcam_status": { "type": "string" }
+  }
+}