feat: add support for SDCP v3.0.0

[amd989]

Summary

Implements the device side of SDCP (Smart Device Control Protocol) v3.0.0, the protocol ChiTu network-capable mainboards speak natively. ChiTuBox and other SDCP clients now discover and drive Mariner as though the printer had network support built in: no client-side configuration, no custom endpoint mapping.

Follows up #15, which added the provider framework and UVTools support.

Why this needed a new provider shape

The UVTools provider is a set of Flask routes on Mariner's existing web port. SDCP cannot work that way: the protocol hard-codes its ports (UDP 3000 for discovery, 3030 for both the WebSocket and file upload), and the discovery reply carries no port number, so clients assume them.

NetworkPrintProvider now supports two modes:

Mode	Implement	Used by
Routes on Mariner's web port	register_routes()	UVTools
Own listeners	provides_http_routes = False + start()	SDCP

start() is called from main(), never at import time, so importing the app in tests or under a WSGI loader never binds a port. A provider that fails to start is logged and skipped rather than taking the server down. register_routes() is no longer abstract, and get_provider_prefixes() only reports providers that actually own a URL prefix.

What's implemented

• Discovery: answers the M99999 UDP broadcast on port 3000 with name, model, mainboard ID, and the local IP as routed to the requesting client (correct on multi-homed hosts).
• Control channel: WebSocket on port 3030 at /websocket, carrying commands, live status, and printer attributes on the spec's topic scheme. Pushes attributes and status on connect, then on change.
• File transfer: chunked multipart uploads at POST :3030/uploadFile/upload, verified against the client's MD5. Chunks are assembled in a scratch directory inside the files directory so the final move is an atomic same-filesystem rename rather than a copy of a large file.

Serial I/O and file assembly run through an executor, so polling the printer never blocks the event loop. Status polling only runs while a client is connected, since it shares the serial link with the web UI.

Command coverage

Cmd	Operation
0 / 1	Refresh status / attributes
128	Start printing
129 / 130 / 131	Pause / stop / resume
132 / 133	Stop feeding / skip preheat (accepted as no-ops)
192	Change printer name
255	Terminate in-flight transfer
258 / 259	List files / batch delete
320 / 321	Historical tasks
386 / 387	Video stream / time-lapse

Limitations, encoded rather than faked

Where Mariner cannot reach the hardware SDCP models, the response says so instead of pretending:

• Video stream (386) reports that no camera exists; time-lapse (387) reports failure.
• History (320/321) returns empty lists. Mariner keeps no task history.
• Print sub-status is always EXPOSURING during a print. The serial link has no notion of the lift/drop phases the protocol models.
• Rename (192) applies for the lifetime of the process. The service does not rewrite config.toml.

Layer progress is derived from the print file using the same helper the web UI uses, so both surfaces report the same layer.

Two things worth a closer look

1. New runtime dependency: aiohttp ^3.9 (plus 8 transitive). It serves the WebSocket and the upload endpoint on one port and hosts the UDP listener on the same event loop, so it replaces what would otherwise be several libraries. Also added to .pyre_configuration search path, without which CI fails on Undefined import.
2. Enabled by default. SDCP binds two listeners and answers broadcasts on the LAN. This is what makes it work with zero client setup, but it is a new network-facing surface. Set enabled = false under [sdcp] to turn it off. If either port is already in use, Mariner logs an error and continues serving the web interface normally.

Configuration

Works with no configuration. Everything is pinnable:

[sdcp]
enabled = true
brand_name = "CBD"
machine_name = "Mars 3"       # defaults to printer.display_name
firmware_version = "V1.0.0"
resolution = "1440x2560"      # derived from a sliced file when unset
xyz_size = "68.04x120.96x150"
mainboard_id = ""             # derived from the host machine-id when unset
discovery_port = 3000
server_port = 3030
poll_interval_secs = 3.0

The mainboard ID is derived from the host's machine-id so it stays stable across restarts, which is what lets clients remember the printer.

Testing

• 39 unit tests covering message envelopes, storage-prefix handling, status and attribute mapping, print control, file listing and deletion, and the upload state machine (offset ordering, MD5 verification, restart-at-zero, filename sanitisation, termination).
• End-to-end smoke test against a live service with a mocked printer: 40 checks across discovery, WebSocket handshake, heartbeat, chunked upload with MD5 verification and a deliberate MD5 failure, file listing, and every print control command. All pass.
• Path traversal is covered on start, list, delete, and upload.
• Full suite: 136 pass. The 9 failures are pre-existing on master (os.sync under pyfakefs and Z-position layer assertions) and are unchanged by this PR.
• black and flake8 clean. pyre was not run locally (no Windows binary); strict-mode annotations were added pre-emptively.

Docs

docs/network-printing.rst gains an SDCP section covering setup, command coverage, limitations, and configuration. The "Adding more providers" section now documents both provider modes.