refactor(dns): fall back to Cloudflare DNS instead of Google

[alkaz-nodemaven]

Closes #608.

When TokioResolver::builder_tokio() fails to read the system resolver config, src/dns.rs falls back to ResolverConfig::default(). In hickory-resolver 0.25.2 that is ResolverConfig::google():

impl Default for ResolverConfig {
    fn default() -> Self {
        Self::google()
    }
}

So the fallback is 8.8.8.8, which does not work from mainland China and the lookup times out. This is the path Termux takes, since it has no /etc/resolv.conf.

Checked against 0.25.2 rather than assumed — the two configs resolve to:

default()      -> 8.8.8.8:53, 8.8.4.4:53, [2001:4860:4860::8888]:53, [2001:4860:4860::8844]:53
cloudflare()   -> 1.1.1.1:53, 1.0.0.1:53, [2606:4700:4700::1111]:53, [2606:4700:4700::1001]:53

ResolverConfig::cloudflare() is plain UDP/TCP on port 53 and carries no feature gate, unlike cloudflare_tls(), so it is a drop-in swap at the same call site.

The eprintln! and the doc comment said "defaults" and now name Cloudflare, so they don't drift from the code.

Notes

• Existing users are unaffected unless the system config is unreadable; the builder_tokio() success path is untouched. DnsOptions(system_dns=True) remains the way to bypass hickory entirely.
• No test. The fallback only runs when the system config fails to load, which isn't reachable from tests/, and the crate has no #[cfg(test)] modules to extend. Say if you want the config extracted into a helper so it can be asserted on.
• build(deps): bump hickory-resolver from 0.25.2 to 0.26.3 #613 bumps hickory to 0.26.3, where ResolverConfig has no Default and the providers are ServerGroup constants. This line has to change either way; happy to rebase whichever lands second.

What I did not verify

The crate does not build on my machine — btls-sys needs nasm for BoringSSL — so I ran cargo fmt --all -- --check only, not cargo clippy. The swap and the call site were type-checked against hickory-resolver 0.25.2 in a separate crate, which is where the two lines of output above come from. I also could not reproduce the original timeout: no Android device here.