Expose control_print, and say what the gateway's ok does not mean

The route's body is `PrinterCommandSchema` straight from the shared schema,
so adding the variant there is what exposes it here - that is the point of
taking the type from one place. What needed saying is in the comments: stop
is a cancel with no undo, and a gateway returning ok means the printer
accepted the command rather than that the print state changed, since an idle
P1P answers success to all three verbs. A UI that puts stop where pause is
expected, or that treats the 200 as confirmation, gets this wrong.

The contract test gains the three control frames and one guard: a verb only
one vendor recognises - `cancel`, Moonraker's word for it - must not
validate, or it reaches a gateway that cannot map it. Mirrored in
continuum-proxy/tests/uplink_protocol.rs.

src/routes/printers.ts

@@ -131,6 +131,14 @@ export const printerRoutes = new Elysia({ prefix: "/printers" })
    * physical machine, and the blast radius of getting this boundary wrong is
    * a ruined print or a hot end driven into a plate. It is the one role
    * boundary here that is not about data.
+   *
+   * As of 2026-10-11 the set includes `control_print`, whose `stop` is a
+   * cancel: confirmed on a real P1P, it ends the running print and the
+   * printer then reports `FAILED`. There is no undo, so a UI must not put it
+   * where `pause` is expected. Note also that a gateway returning `ok` means
+   * the printer *accepted* the command - on an idle P1P all three verbs
+   * answer success - so whether the state changed has to be read back from
+   * telemetry.
    */
   .post(
     "/:id/commands",
@@ -166,8 +174,10 @@ export const printerRoutes = new Elysia({ prefix: "/printers" })
     },
     // The same command set the gateway accepts, straight from the shared
     // schema - so this route cannot drift into offering something no gateway
-    // can execute. Note what is absent: there is no "start a print" command
-    // yet, deliberately.
+    // can execute. Note what is absent: there is still no "start a print"
+    // command, though no longer because the path is unproven (it was
+    // confirmed on a real P1P on 2026-10-11) - nothing uploads a sliced file
+    // to a gateway, and nothing decides which printer runs which job.
     { params: IdParams, body: PrinterCommandSchema, detail: { tags: ["printers"] } },
   )
   .get(