resolver: a reply marked recursion available from a root server's address stops the lookup (closes #300)

dnswatcher never asks for recursion and a root server never offers it,
so a reply marked recursion available from a root server's address
came from a resolver on the network answering in its place. The first
such reply now stops the lookup at once with the existing "this network
intercepts DNS queries", naming the address, and no other root server
is asked, whether or not that resolver had the name cached. Before, a
cached name was checked against the resolver's second-hand answer.

On such a network dnswatcher and its tests fail with that error, by
design; nothing works around the interception. A live test passes
public resolvers as the root servers and expects the error.

Model: opus-5-5

README.md

@@ -561,6 +561,18 @@ This approach ensures:
 - Ability to detect split-horizon or inconsistent responses across authoritative
   servers.
 
+A root server never offers recursion, so a reply marked "recursion available"
+from a root server's address came from a recursive resolver on the network
+answering in its place, as on a network where a router rule, a VPN or a DNS
+filter sends all DNS to one resolver. The first such reply from a root server's
+address stops the lookup at once with the error "this network intercepts DNS
+queries", and no other root server is asked. A lookup that every root server
+refuses fails with the same error. Every lookup starts at the root servers, so
+on such a network every lookup fails with that error, whether or not that
+resolver has the name cached, and dnswatcher's tests fail there too. That is by
+design: nothing asks again another way or otherwise works around the
+interception.
+
 A watched name's records are stored as its nameservers return them, CNAME
 included. When they return a CNAME and no address, the chain of every CNAME
 target they gave is followed (with a depth limit to prevent loops) to the A and