discovery: also resolve peers over the n0 pkarr HTTPS relay on native targets

[Kiraprint]

Fixes the native-target half of #54.

Problem

On non-wasm targets the N0 preset wires up only DnsDiscovery — the PkarrResolver
(HTTPS GET https://dns.iroh.link/pkarr/<z32>) is added for wasm_browser only:

#[cfg(wasm_browser)]
{ builder = builder.discovery(PkarrResolver::n0_dns()); }

#[cfg(not(wasm_browser))]
{ builder = builder.discovery(DnsDiscovery::n0_dns()); }   // DNS TXT only

So a native iroh-ssh client depends entirely on n0's DNS zone staying in sync with the
pkarr store. When it does not, dialling a perfectly reachable peer fails with:

Error: No addressing information available

Caused by:
    0: Discovery service failed
    1: Discovery produced no results for <endpoint id>

which is exactly the report in #54.

Evidence

While the TXT record was missing, the pkarr record was served normally:

$ dig TXT _iroh4.<z32>.dns.iroh.link @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN      # also via 8.8.8.8 and the authoritative ns1.iroh.link

$ curl -o /dev/null -w '%{http_code} %{size_download}\n' https://dns.iroh.link/pkarr/<z32>
200 208

The endpoint was up and its SSH port reachable the whole time; only discovery failed.

Fix

Add the pkarr HTTPS resolver as a second lookup path on native targets. Builder::discovery
appends, and iroh races the configured resolvers, so this is additive — healthy DNS setups
are unaffected.

#[cfg(not(target_arch = "wasm32"))]
{
    use iroh::discovery::pkarr::PkarrResolver;
    builder = builder.discovery(PkarrResolver::n0_dns());
}

No new dependencies (the resolver is already in iroh, and is already compiled in for wasm),
no CLI changes, no behavioural change when DNS works.

Verification

With the TXT record returning NXDOMAIN and the pkarr record at HTTP 200/208 bytes:

• before: Error: No addressing information available (the Bug:address look up #54 report)
• after: connection established, -L forward bound, HTTP 200 from the service behind it

I also keep an explicit-relay dial available in a separate branch (--relay-url pinning the
peer's home relay) as a fallback for networks where n0 discovery is blocked entirely, but that
requires knowing the peer's relay and does not fix the common case this patch addresses.

[Kiraprint]

Closing this — the diagnosis behind it was wrong, and I don't want to leave a misleading PR open.

I claimed n0's DNS zone was not serving the endpoint TXT record. That was based on querying
_iroh4.<z32>.dns.iroh.link. That name does not exist: _iroh4 came from misreading DNS wire
bytes — \x05_iroh (label) followed by \x34 (52 = the length of the z32 label, which happens
to be ASCII 4) reads as the text _iroh4. The real name, IROH_TXT_NAME + z32
(_iroh.<z32>.dns.iroh.link), resolves correctly:

$ dig TXT _iroh.57mr4k9n….dns.iroh.link @1.1.1.1
;; status: NOERROR
_iroh.57mr4k9n….dns.iroh.link. 30 IN TXT "relay=https://use1-1.relay.n0.iroh-canary.iroh.link./"

So the zone is healthy and there is nothing to fix here. My "before" reproduction was also an
artifact: the test pointed the resolver at a port where nothing was listening, so DNS failed
for all names.

Apologies for the noise. (For what it's worth, the extra HTTPS lookup path does not bypass a
broken resolver either: iroh's PkarrResolver resolves its relay host through the same
DnsResolver.)