Closes #21. wf_handle_resolve tried DNS TXT, then only on failure tried well-known HTTPS -- always paying both round trips' worst-case latency in the fallback case, and never getting the latency benefit of whichever method happens to be faster on a given network. The reference fires both concurrently and takes whichever settles first (packages/identity/src/handle/index.ts). True cancellation of an in-flight c-ares query or libcurl request isn't safe to do with pthread_cancel -- both could be left holding state a forced cancellation corrupts. Instead this launches both lookups as detached threads sharing a refcounted result struct, returns as soon as either succeeds, and lets the loser finish in the background and clean up its own share of the struct when it does. Neither wf_handle_resolve_dns_txt (a fresh ares_channel_t per call) nor wf_handle_resolve_well_known (client requests are already safe for concurrent use, see wf_client_snapshot in xrpc.c) has shared mutable state for two concurrent calls to contend over. Verified race-free under ThreadSanitizer (test_identity, several runs, zero reports) given this is exactly the kind of code where "tests passed" alone isn't sufficient confidence. Backup-nameserver support (the other half of #21) is not included here -- c-ares's server-list configuration is a coarser, channel-wide setting that doesn't compose cleanly with per-call racing the way this change is scoped, and deserves its own pass rather than being folded in.