Add msg to v1 push_status, and say why v2 has no vt_tray

Two things the live captures showed that the schemas did not say.

`msg` was missing from the v1 push_status schema, which is the one version
where it is load-bearing. v1 pushes only the fields that changed, except for
a pushall-triggered push which is the whole object, and `msg` is how a v1
message self-describes which it is (0 forced/full, 1 automatic/partial). A
consumer that replaces its cached object with a partial push silently unsets
every field that push did not mention, and there is no other way to tell:
push_status does not echo `sequence_id`, so there is no correlation back to
the pushall that asked for it. continuum-proxy has read this field since the
cache was written; the schema just never declared it.

v2 had it with no description. It is informational there - v2 sends the whole
object every time - so it now points at the v1 note rather than repeating it.

The other half is an absence, which a schema cannot express by staying
silent: v2 has no `vt_tray` because a real v2 printer omits the key entirely
rather than sending an empty object. That is recorded as a comment so nobody
adds it for symmetry with v1, because the distinction is the thing: absence
means "not reported", not "no external spool", and it is exactly why
`EXTERNAL_SPOOLS` in continuum-proxy is a constant instead of being counted
from a report.

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

@@ -10,6 +10,11 @@
       "properties": {
         "command": { "const": "push_status" },
 
+        "msg": {
+          "type": "integer",
+          "description": "Whether this push is the whole object or only what changed: 0 forced/full (what a pushing.pushall triggers), 1 automatic/partial. Confirmed against a real printer. A v1 consumer MUST read this - merging a partial push as if it were full leaves the picture complete, but replacing the cached object with a partial one silently unsets every field the push did not mention. It cannot be inferred any other way, because push_status does not echo sequence_id (see the module description), so there is no correlation back to the pushall that asked for it. v2 sends the whole object every time and this field is informational there."
+        },
+
         "upgrade_state": { "$ref": "../../common/upgrade_state.schema.json" },
         "ipcam": { "$ref": "../../common/ipcam.schema.json" },
         "upload": { "$ref": "../../common/upload.schema.json" },

schemas/bambulab/v2/report/print/push_status.schema.json

@@ -10,6 +10,8 @@
       "properties": {
         "command": { "const": "push_status" },
 
+        "_comment_no_vt_tray": "There is deliberately no vt_tray here. A real v2 printer omits the key entirely rather than sending an empty object, confirmed live, so absence means 'not reported' and not 'no external spool' - do not add it to make this symmetrical with v1. It is why the external-spool count cannot be derived from a report: counting reported spools would give 0 on exactly the dual-nozzle H2C that has two (see common/ams/ams_mapping.schema.json).",
+
         "2D": { "$ref": "./_2d_report.schema.json" },
         "3D": { "$ref": "./_3d_report.schema.json" },
         "ams": { "$ref": "../../common/ams/ams.schema.json" },
@@ -85,7 +87,10 @@
         "mc_stage": { "type": "integer" },
 
         "model_id": { "type": "string" },
-        "msg": { "type": "integer" },
+        "msg": {
+          "type": "integer",
+          "description": "Full-vs-partial indicator, as in v1 (0 forced/full, 1 automatic/partial) - but informational here, because v2 sends the entire object on every push. The v1 schema carries the full note on why a v1 consumer must read it."
+        },
 
         "percent": { "type": "integer" },
         "plate_cnt": { "type": "integer" },