Answer DNS over both families, and only for our own interface

Questions now arrive over IPv4 or IPv6, whichever the resolver uses. The
server opens one listener per family — the overlay address or `127.0.0.1`,
and `[::1]` — and all of them are published to systemd-resolved in one
call, which is what that call requires: sending them one at a time leaves
only the last. A family that cannot be bound, IPv6 switched off in the
kernel for instance, no longer stops the other from answering.

The answers stay IPv4, because that is what the overlay is. A listening
address is disposable, unlike an address a member holds in signed state,
so serving one family over the overlay and the other over loopback costs
nothing and loses nothing.

`--no-tun` was also configuring the host. An in-memory interface has a
name and an MTU and nothing else, but everything downstream read that name
as a host interface: the resolver setting was pushed onto whatever else on
the host happened to be called `tsun0` — which, with two agents on one
machine, is another agent's live interface. A factory now says whether
what it creates is on the host, and the resolver setting goes only to an
interface the agent created. For the same reason the complaint that "the
allocated address is not on any interface" no longer fires under
`--no-tun`, where there was never going to be one; it had people looking
for something that had removed their address. The status line says
`tsun0 (in memory, --no-tun)` rather than printing an address beside a name
the operating system does not have.

That distinction also corrected a test that used the in-memory interface
as a stand-in for an unconfigured host interface. They are not the same
case, so the test now uses a factory that claims the host and puts nothing
there — a provisioner that reported a success it did not achieve — and a
second test covers `--no-tun` being an arrangement rather than a fault.

An in-memory device now reports end of stream when it is destroyed. It
never did, so the packet loop reading it could not end, and since shutdown
became bounded that cost every `--no-tun` agent the full five-second grace
before the loop was aborted instead of finishing.

And `status` says when there is no local resolver at all. Its absence is
the answer to "why does this name not resolve?", and leaving the section
out made a report with DNS switched off look exactly like one where it was
running.

The local control protocol is 7: `DnsReport` carries a list of listening
addresses and `OverlayReport` says whether the interface is on the host.

Verified against the running systemd-resolved: it takes
`127.0.0.1:5354 [::1]:5354` on one link in a single call, and forward and
reverse questions for a peer's name are answered identically over both
transports.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -195,11 +195,15 @@ dig @10.13.37.69 -p 5354 music.lab
 ```
 
 Names come from signed state, which is the point: **a member that is
-switched off still resolves**, because its claim outlived the session. IPv4
-only — the IPv6 overlay address derives from a key that travels in live
-announcements, so it cannot be answered for a member that is away, and
-answering for some members and not others depending on who is online is
-worse than not answering.
+switched off still resolves**, because its claim outlived the session.
+
+The answers are IPv4 addresses, because that is what the overlay is. The
+*questions* are taken over both families, on UDP and TCP: the server listens
+on the overlay address and on `127.0.0.1`, and on `[::1]` for IPv6, so a
+resolver reaches it over whichever it uses. All of those are published to
+the system resolver together. A listening address is disposable — unlike an
+address a member holds in signed state — so serving one family over the
+overlay and the other over loopback costs nothing.
 
 The zone is the network name unless `--dns-zone` says otherwise. It is
 yours to choose, so a name that shadows a real public domain is reported and
@@ -212,6 +216,11 @@ here, over D-Bus, scoped to the overlay interface and as a *routing* domain
 so it never becomes the resolver for anything else. resolved drops the whole
 setting when the interface goes, and the interface goes with the agent.
 
+Only an interface the agent created, though. Under `--no-tun` there is no
+host interface at all, and the agent says so and serves the zone on
+loopback rather than configuring whatever else on the host happens to share
+the name.
+
 That last step needs permission that `CAP_NET_ADMIN` does not give:
 systemd-resolved asks polkit, and polkit decides by **user**, not by
 capability, so there is no way for the agent to arrange it from inside. On