revert(searxng): return search egress to direct NH3

Reverts the outgoing.proxies block added in 156e126. Canonical restored from
that commit's parent and verified byte-identical to the host's
searxng-settings.yml.pre-esh-20260917 backup, then deployed via
scripts/deploy-stack.sh so canonical and host converge rather than drift. The
esh-scale searxng-egress.service is stopped and disabled; tailscaled on that
container was not touched.

⚠ THE ROLLBACK DID NOT RESTORE THE ENGINES, WHICH FALSIFIES THE REASON GIVEN
FOR IT. 156e126 recorded that moving egress to ESH had cost three of four
engines. Measured after this revert, with egress confirmed back on
70.230.226.88 and the same instrument used for the before-measurement, the
result is identical: brave and startpage suspended, duckduckgo CAPTCHA, google
cse the only engine answering. Per-engine bang probes confirm duckduckgo is
CAPTCHA-ing the residential address live, so this is not a stale suspension
timer.

The engine failures therefore have some other cause and predate or are
independent of the ESH move. The claim in 156e126 asserted causation from a
correlation without measuring the pre-change state; the only evidence for
"residential egress avoids CAPTCHAs" was a comment dated 2026-09-03, which is
no longer true of this address.

The revert still stands on its own merits: ESH egress bought no measurable
improvement while adding a hard dependency on ESH WAN and mesh availability
for all fleet search, so the simpler configuration is the better one. It is
simply not the fix for the engines.

README rewritten to match: direct NH3 is documented as current, the ESH
attempt is kept as history with its measured outcome, and the health script's
blind spot is called out — scripts/searxng-health.sh prints a passing result
while three engines are blocked, because it gates on "any results returned"
and treats failed engines as informational. That script needs to fail on
blocked engines before any future egress change, or the next regression is
equally invisible.

stacks/searxng/conf/searxng-settings.yml

@@ -3,9 +3,10 @@
 # ⚠ WHY NH3 AND NOT THE COLO. Measured 2026-09-03:
 #     ana-docker egress  38.120.12.42   (datacenter) -> DuckDuckGo + Startpage CAPTCHA
 #     nh3-docker egress  70.230.226.88  (residential) -> no CAPTCHA
-# Since 2026-09-17, search requests exit via a restricted SOCKS5 listener on
-# esh-scale (10.0.50.65:1080), per operator request. Hosting remains at NH3.
-# No host default-route or mesh routing changes. See stacks/searxng/README.md.
+#   Search engines gate datacenter ranges. Same reason the fleet keeps a
+#   residential SOCKS5 egress proxy on nh3-dev for yt-dlp. Running the search
+#   aggregator from a residential-egress site removes the problem at the source
+#   rather than proxying around it.
 
 use_default_settings:
   engines:
@@ -71,8 +72,8 @@ outgoing:
   pool_connections: 100
   pool_maxsize: 20
   enable_http2: true
-  # ESH-only search egress; resolve engine hostnames at the proxy.
-  # No direct fallback: an ESH outage must not silently switch back to NH3.
-  proxies:
-    all://:
-      - socks5h://10.0.50.65:1080
+  # No proxy needed: this host already egresses residentially (see header).
+  # If that ever changes, the fleet's NH3 SOCKS5 proxy is the fallback:
+  #   proxies:
+  #     all://:
+  #       - socks5h://10.100.10.50:1080