Report discovered printers to the cloud, off by default

The gateway could already find printers; only a human reading a terminal
could see the result. So adding a printer in the web console still began with
walking to a machine to read its IP address off the screen.

Now a background task scans on a timer and sends a `discovered_printers`
frame. It cannot finish the job - the credential is on that screen and no
probe can read it - but it removes the address, the serial and the guesswork
about which vendor the thing is.

OFF by default, which is the load-bearing part of this commit. A /24 sweep is
254 TLS handshakes and up to three HTTP requests per host, and nothing
watching can tell that from a port scan; on a corporate network, being
indistinguishable from a port scan is itself the problem. A gateway that did
this by default would scan networks its operator never meant to point it at,
and the first they would hear of it is from their own security team. So:

- `discovery.enabled` is false unless set, per gateway, in that gateway's own
  config. The cloud cannot switch it on. A setting whose whole purpose is to
  bound what this process does to the local network has to be decided where
  that network is understood, which is not in a data centre.
- `subnets` is explicit, never derived from this host's interfaces, so a
  second NIC, a VPN or a container bridge cannot widen the sweep. Anything
  wider than a /24 is still refused, now at config-import time rather than
  when the timer first fires.
- A flag that is neither `true` nor `false` is an error, not a shrug. The two
  readings of a typo are not equally safe.
- Naming a subnet without setting `enabled` scans nothing - the safe reading
  of an incomplete instruction - and `enabled` with nowhere to look is
  refused as the mistake it is.
- The env var can switch it *off* over a file that enables it, which is the
  direction that has to work: a Proxy Box's config is signed in the cloud, so
  an operator who finds their gateway probing cannot just edit it.

What a scheduled scan will not do, unlike the example CLI: send `M115`.
Opening a serial port toggles DTR, which reboots an Arduino-based board and
ruins a print in progress. The example can do it behind
`--yes-reset-the-printer` because a human is standing there; a timer has
nobody to ask, so it does not get the option and reads sysfs instead.

Two things that took more care than expected:

`Scan::looked()`. An empty report means "this gateway looked and its network
has no unconfigured printers", so sending one after every probe failed would
state something untrue about the farm. A partial failure is still evidence,
though - withholding a good sweep because a container can never bind SSDP
would suppress it forever - so the test is "did anything succeed", not "did
everything".

`fleet::configured()` reads the fleet file at parse level rather than through
`load`, because the entry it most needs to recognise is the one `load`
refuses: a printer discovery suggested, pasted in, with the access code not
yet typed in. Re-offering that printer as a fresh find is noise at the one
moment the operator is mid-way through adding it.

Verified against the real LAN: a sweep found both printers by TLS certificate
with correct serials and no credentials, and the frame it produced validates
against the backend's EdgeClientMessageSchema. The `wire` subcommand on the
example prints exactly that frame, and the capture is pinned as a backend
fixture. SSDP remains untestable here - this container is a router hop from
the printers and multicast does not cross one.

src/uplink/mod.rs

@@ -30,7 +30,7 @@ mod download;
 mod webrtc;
 mod protocol;
 
-pub use protocol::{ClientMessage, PrinterCommand, PrinterTelemetry, ServerMessage};
+pub use protocol::{ClientMessage, DiscoveredPrinter, PrinterCommand, PrinterTelemetry, ServerMessage};
 
 use std::sync::Arc;
 use std::time::Duration;
@@ -119,13 +119,29 @@ fn host_header(url: &str) -> anyhow::Result<String> {
     Ok(authority.to_string())
 }
 
+/// The queue a task elsewhere puts a message on to have the uplink send it.
+///
+/// Created by the caller rather than inside [`run`] so that a task which is
+/// not the uplink - printer discovery, today - can hold the sender without
+/// the uplink having to know what those tasks are. The property that matters
+/// is unchanged either way: it outlives any one connection, so a message
+/// produced while the socket is down waits for the next socket instead of
+/// being dropped, and the sender living for the whole program is what stops
+/// `recv()` from ever returning `None`.
+pub fn channel() -> (
+    tokio::sync::mpsc::Sender<ClientMessage>,
+    tokio::sync::mpsc::Receiver<ClientMessage>,
+) {
+    tokio::sync::mpsc::channel(OUTBOUND_CAPACITY)
+}
+
 /// Runs forever: connect, serve the connection until it drops, wait, retry.
-pub async fn run(config: Config, fleet: SharedFleet) {
-    // Created out here, not per connection, so a message produced while the
-    // socket is down waits for the next one instead of being dropped. The
-    // sender is kept for the whole program's life, which is also what stops
-    // `recv()` below from ever returning `None`.
-    let (outbound, mut inbox) = tokio::sync::mpsc::channel::<ClientMessage>(OUTBOUND_CAPACITY);
+pub async fn run(
+    config: Config,
+    fleet: SharedFleet,
+    outbound: tokio::sync::mpsc::Sender<ClientMessage>,
+    mut inbox: tokio::sync::mpsc::Receiver<ClientMessage>,
+) {
     let mut delay = RETRY_DELAY;
 
     loop {