Scan the LAN, bounded to configured subnets (#257)

internal/netscan/ discovers hosts on the network Maven is configured to look at:
a TCP-connect scan (net.DialTimeout, no raw sockets, no privileges) plus a read
of the kernel's ARP cache. Wired as a read-only query source, "network", so
"какие устройства в сети?" is answered by a scan instead of by whatever old note
happens to be nearest.

Scanning is a read, but an unbounded scanner on a home LAN is noisy and easy to
point somewhere it should not go, so the package is built around four bounds:

  - Scan takes NO target argument. The range comes from the config block and
    from nowhere else, so there is no exported way to scan an arbitrary prefix
    and nothing an utterance, the router, or a scanned host says can retarget
    it. That is asserted directly: the test watches every address handed to the
    dialer and fails if one falls outside the configured prefix. The ARP cache —
    the one input the network itself populates — is filtered to the configured
    range for the same reason.
  - Every configured CIDR must be private (RFC1918 / CGNAT / link-local) and no
    larger than 1024 addresses. 8.8.8.0/24, 0.0.0.0/0 and 10.0.0.0/8 are refused
    at config load, not after the packets have left.
  - Rate-limited to a configured connections-per-second across the whole scan,
    so it looks like background traffic rather than a portscan.
  - Bounded in total by MaxHosts, a per-connection timeout, a 20s turn budget
    and the context; a canceled scan stops dialing immediately.

Off unless configured: dark without "enabled": true, and applyDefaults
normalises a disabled block to nil. deploy/mavend.json carries it disabled.

BLUETOOTH IS NOT SHIPPED, AND IS BLOCKED, NOT SKIPPED. The plan's other half
(internal/bluetooth/, RSSI presence probes) needs a bluez stack that is not
here: bluetoothctl and hcitool are not installed, bluetoothd is not installed,
the bluetooth unit is inactive, and org.bluez is not on the system bus. hci0
exists as a kernel device and nothing can talk to it. The docker deploy is
further away still — it would need host networking, the D-Bus system socket
passed in, and CAP_NET_ADMIN. Writing an exec wrapper around a binary that does
not exist, against an output format nothing here can produce, would be a guess
dressed as a feature. It needs a decision about privileging the container before
any of it is worth writing.

Vikunja #257

cmd/mavend/actions_query.go

@@ -81,6 +81,11 @@ var querySources = []querySource{
 	// wording, so "какая температура на улице?" still reaches the weather
 	// source.
 	{"home", (*reactiveHandler).queryHome},
+	// Next to "home" and for the same reason: "какие устройства в сети?" is a
+	// question about the LAN, and the recall pass would otherwise answer it
+	// from an old note about the router. Its matcher needs a network word plus
+	// an ask plus a device noun, so "интернет не работает" is untouched.
+	{"network", (*reactiveHandler).queryNetwork},
 	{"calendar", (*reactiveHandler).queryCalendar},
 	{"weather", (*reactiveHandler).queryWeather},
 	{"embed", (*reactiveHandler).queryEmbed},
@@ -299,6 +304,22 @@ func (h *reactiveHandler) queryHome(ctx context.Context, t *queryTurn) (string,
 	return h.home.homeSummary(ctxH)
 }
 
+// queryNetwork answers a question about the LAN with a bounded scan. There is
+// no confirm turn because nothing is changed, and no way to widen the range
+// because Scan takes no target — the utterance selects the question, never the
+// subnet.
+func (h *reactiveHandler) queryNetwork(ctx context.Context, t *queryTurn) (string, bool) {
+	if !isNetworkQuery(t.dec.Utterance) {
+		return "", false
+	}
+	if h.netscan == nil {
+		// Claim the turn: "сканирование не настроено" is true, and general
+		// knowledge would answer with an invented list of devices.
+		return "сканирование сети не настроено.", true
+	}
+	return h.netscan.scanSummary(ctx)
+}
+
 func (h *reactiveHandler) queryWeather(ctx context.Context, t *queryTurn) (string, bool) {
 	if !isWeatherQuery(t.dec.Utterance) {
 		return "", false