fix(engine): drop hickory-dns so direct egress resolves in Docker

[us]

Problem

On prod (Docker) every DIRECT outbound HTTPS call from the engine failed with reqwest error sending request for url (...): managed-LLM calls (structured extract → 502), and the research APIs (OpenAlex / Semantic Scholar / arXiv / crossref) and Wikidata. Scraping was unaffected because it egresses through the HTTP proxy, which resolves the target itself.

Root cause: the workspace reqwest client is built with the hickory-dns feature, so hickory (trust-dns) is the default resolver. In the container it cannot resolve external hostnames (notably the managed-LLM endpoint, a CNAME chain) through Docker's embedded DNS at 127.0.0.11.

Isolation (all on the prod box):

• glibc getaddrinfo resolves the host fine (getent 6/6; curl from an identical container gets HTTP 200).
• The engine's reqwest fails every time.
• Adding the host to the container /etc/hosts (bypassing DNS) makes extract return HTTP 200. Fault isolated to hickory DNS resolution.

Fix

Remove the hickory-dns feature from the workspace reqwest dependency (root Cargo.toml). reqwest falls back to the system getaddrinfo resolver, which reads /etc/resolv.conf natively and resolves both external CNAME chains and internal service names (searxng-internal, chrome) through Docker DNS. getaddrinfo runs on tokio's blocking pool, so it does not block the async runtime.

All 8 crates inherit reqwest = { workspace = true }, so this single change fixes every direct-egress client at once; no Rust code referenced the hickory resolver. socks/rustls and the rest of the feature set are unchanged, so the proxy scrape path is untouched. Reverts to the resolver used before the Phase B latency change; quality-neutral.

Trade-off

Gives up hickory's in-process cross-request DNS cache (the Phase B latency micro-opt). Impact is small: on prod the scrape/crawl fan-out egresses via the proxy (engine-side DNS cache never applied there), reqwest keep-alive pooling skips DNS on the hot path, and Docker/OS caches repeat lookups.

Verification

Pre-commit green locally: cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo build, cargo test (1228 passed).

DNS behavior is environment-dependent (Docker embedded DNS), so it is not unit-testable in CI. Deploy-time check (with the temporary /etc/hosts pin removed):

1. POST /api/v1/extract with a jsonSchema, paid-plan (Hobby+) key → expect HTTP 200 with structured data (was 502).
2. GET /api/v2/search/research/papers?query=<q>&k=3 → expect HTTP 200 with non-empty hits.
3. Sanity: a normal scrape and a search still return 200.