v0.9.4: actionable diagnostic when outbound TLS to Google edge fails (#18 follow-up)

@Behzad9 reports: after the EMFILE fix in v0.9.3 landed cleanly, the
relay now fails with a different error:

    ERROR Relay failed: io: invalid peer certificate: UnknownIssuer

repeated on every request. This is rustls (via domain_fronter) rejecting
the server cert that whatever sits on our TLS connection to google_ip
presents. In practice this means one of three things, in decreasing
order of likelihood for an Iranian OpenWRT user:

  1. The ISP / a middlebox is intercepting outbound TLS to Google IPs
     and presenting its own cert. webpki-roots (Mozilla trust store,
     baked in) correctly rejects it.
  2. The user's google_ip setting points at a non-Google host.
  3. Router clock is wildly off (NTP not synced), certs look not-yet-valid.

Before this change: one identical ERROR per failed relay, no guidance.
Log filled with the same line.

Now:
  - New DomainFronter::log_relay_failure() detects cert-related error
    strings (UnknownIssuer, CertificateExpired, CertNotValidYet,
    NotValidForName, 'invalid peer certificate').
  - First occurrence logs an ERROR with the three root causes and three
    concrete fixes: run  to find a working Google IP,
    check the system clock, or as a LAST RESORT set verify_ssl=false
    (with the explicit warning that traffic is then only protected by
    the Apps Script auth_key, not outer TLS).
  - Subsequent occurrences drop to debug so the log stays readable —
    an AtomicBool gate on the DomainFronter instance tracks whether
    the hint was shown. Resets on proxy restart.
  - Non-cert errors still log at error level unchanged.

49 tests pass, no code-path regressions (log line content changed, not
behavior). Shipping so users hit this get actionable output.

Cargo.lock

@@ -1317,7 +1317,7 @@ dependencies = [
 
 [[package]]
 name = "mhrv-rs"
-version = "0.9.3"
+version = "0.9.4"
 dependencies = [
  "base64 0.22.1",
  "bytes",