fix: harden ip table failover and config verification under extreme networks

[originalix]

Background

Production incident on 2026-07-16 (Slack #C09JEQE8P2L): on mainland-China Wi-Fi without a proxy, tapping a ticker left every request loading forever. Log analysis confirmed two independent root causes:

1. The selection algorithm pinned traffic to the walled domain. After 23 consecutive real-request failures on the direct domain, the triggered speed test still judged the domain "competitive" — the health probe succeeded (813ms) and the IPs were only ~25% faster (below the 30% threshold) — so it re-selected the failing domain, forming a fail → probe → re-pin loop.
2. Config signature verification failed for 18h+ with no way to diagnose. The background runtime was refused when loading the @ethersproject segment (seg:nm.@ethersproject is owned by main in the split-bundle manifest); a catch-all swallowed the error and reported it as "signature verification failed", misleading the investigation toward the CDN. (The segment-ownership fix lands in a separate branch; this PR covers the observability and resilience side.)

Changes (by commit)

Commit	Content
Types & constants	Structured decision/verify types; failover threshold (3) and TTL (5min) constants
Pure endpoint decision	decideEndpoint: reachability beats latency (real-traffic failures override the 30% threshold), symmetric 30% hysteresis against flapping; includes an incident-scenario regression test
Selection rewiring + fast failover	Service adopts the decision function; after 3 consecutive domain failures it switches to the last-best IP immediately (no waiting for a speed test round); fixes the currentSelection === undefined deadlock that could block speed tests forever; persists lastBestIp on every speed test
Speed-test single-flight	Per-domain coalescing + timer dedup, eliminating the ~20 concurrent speed-test storm seen in the incident log
Adapter fail-open	After 3 consecutive transport-level network errors, hosts of that root domain resolve to a builtin/last-best IP for a 5-minute window — covers the main runtime and the cold-start no_config gap (60 occurrences in the incident log); HTTP error responses don't count; failing requests are never replayed (wallet POST double-send risk); recovery on first domain success
Structured verification	Staged failure reasons (verifier_load_failed / signer_mismatch / malformed_signature / missing_signature) — this log line alone would have pinpointed the incident on day one; canonicalization now uses an allowlist of signed fields (extra server-side metadata no longer breaks verification — validated against the real signer); shape guard on the CDN response
LKG + rollback protection	Persists version/generated_at/payloadHash of the last verified config; rejects legitimately-signed but older configs
CDN fetch via IP-capable client	config.onekeycn.com is fetched through the adapter-backed client instead of plain axios, giving the config-delivery path the same wall resistance as business traffic
Server metrics	endpointSwitched / adapterFailover / configVerifyFailed LogToServer events (no PII), so regional failover and verify-failure rates are visible without asking users to upload logs
Kill switch	disableIpTableFailover dev setting + Dev Settings UI entry — the new behaviors can be turned off in production without a rollback

Testing

• 82 tests / 7 suites green (29 new: 11 decision function, 6 fail-open, 12 verification/guard/hash)
• Incident regression cases included: incident regression: domain failing real traffic beats 30% threshold, verifier import failure -> verifier_load_failed (split-bundle incident)
• yarn agent:check --profile pr local checks all pass

Out of scope (tracked separately)

• Split-bundle segment runtime ownership fix (@ethersproject + the mirrored sentry issue) — separate task/PR
• Native log-upload channel (expo-file-system UploadTask bypasses the adapter; the SNI module doesn't support file streams) — separate task
• 30s API timeout tuning — server-side concern, intentionally untouched

Risk & verification suggestions

The largest risk surface is the adapter fail-open (shared by appApiClient / analytics / hardware configFetcher). Constraints: only transport-level errors count, threshold 3 + 5min TTL, exits on first success, kill switch available. Suggested QA: regress the core request paths both with the direct domain blackholed (hosts entry for wallet.onekeycn.com) and on a normal network to confirm no behavior change in the healthy case.