Please address the comments from this code review:

## Overall Comments
- In `openSMTPClient` you create a `context.WithTimeout` but never use the context for dialing (the non-TLS path uses `DialContext` but the TLS path ignores `ctx` and relies only on `Dialer.Timeout`); either wire the context through `tls.Dialer`/`DialContext` or remove the unused context to avoid confusion.
- The SMTP bridge error path currently returns raw `smtp`/network error messages directly in the JSON `message` field, which may leak internal server details to clients; consider wrapping or sanitizing these errors before sending them back to the caller.

## Individual Comments

### Comment 1
<location path="src/server/eo-pages/cloud-functions/smtp.go" line_range="287-291" />
<code_context>
+	return "LOGIN", nil, nil
+}
+
+func (auth loginAuth) Next(fromServer []byte, more bool) ([]byte, error) {
+	if !more {
+		return nil, nil
+	}
+	challenge := strings.ToLower(strings.TrimSpace(string(fromServer)))
+	if strings.Contains(challenge, "user") {
+		return []byte(auth.username), nil
</code_context>
<issue_to_address>
**issue (bug_risk):** SMTP LOGIN challenge handling assumes plain-text prompts, but servers typically send base64-encoded challenges.

Here `fromServer` is interpreted as plain text and matched against "user"/"pass", but real servers send base64-encoded prompts (e.g., `VXNlcm5hbWU6`, `UGFzc3dvcmQ6`). This will cause LOGIN to fail in practice. Please decode the challenge before inspecting it or adopt a more complete LOGIN implementation so the advertised mechanism actually works.
</issue_to_address>

### Comment 2
<location path="src/server/eo-pages/cloud-functions/index.js" line_range="161-170" />
<code_context>
+  }
+}
+
+async function verifySmtpBridgeUrl (url, token) {
+  const host = getSmtpBridgeCandidateHost(url)
+  if (!host) return false
+
+  const nonce = randomBytes(16).toString('hex')
+  let response
+  try {
+    response = await fetch(url, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({ action: 'probe', nonce, bridgeHost: host })
+    })
+  } catch (e) {
+    return false
+  }
+
+  let result
+  try {
+    result = await response.json()
+  } catch (e) {
+    return false
+  }
+
+  const expected = signSmtpBridgeProbe(token, nonce, host)
+  return response.ok &&
+    result.ok &&
+    result.bridgeHost === host &&
+    timingSafeEqualHex(result.signature, expected)
+}
</code_context>
<issue_to_address>
**suggestion (performance):** SMTP bridge URL verification lacks a timeout, risking long hangs when a candidate host is slow or unresponsive.

The `fetch` probe runs without a timeout or abort signal, so `getSmtpBridgeUrl` can block for a long time if a candidate is slow, blackholed, or misconfigured, impacting email tests and post-submit notifications. Please add a per-probe timeout (for example using an `AbortController`) so discovery fails fast when a candidate doesn’t respond promptly.

Suggested implementation:

```javascript
const SMTP_BRIDGE_PROBE_TIMEOUT_MS = 5000

async function verifySmtpBridgeUrl (url, token) {
  const host = getSmtpBridgeCandidateHost(url)
  if (!host) return false

  const nonce = randomBytes(16).toString('hex')
  let response

  const controller = new AbortController()
  const timeoutId = setTimeout(() => {
    controller.abort()
  }, SMTP_BRIDGE_PROBE_TIMEOUT_MS)

  try {
    response = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ action: 'probe', nonce, bridgeHost: host }),
      signal: controller.signal
    })
  } catch (e) {
    return false
  } finally {
    clearTimeout(timeoutId)
  }

  let result
  try {
    result = await response.json()
  } catch (e) {
    return false
  }

  const expected = signSmtpBridgeProbe(token, nonce, host)
  return response.ok &&
    result.ok &&
    result.bridgeHost === host &&
    timingSafeEqualHex(result.signature, expected)
}

```

1. If this file already defines shared timeout/configuration constants, move `SMTP_BRIDGE_PROBE_TIMEOUT_MS` next to them or reuse an existing HTTP timeout constant to stay consistent.
2. Ensure that the runtime environment provides `AbortController` and a `fetch` implementation that supports the `signal` option; if not, add the appropriate polyfill/import at the top of the file (e.g. from `node-fetch` or a similar library).
</issue_to_address>