Three independent inbound-side / outbound-side input-safety bypasses
batched into one PR per request, following PR-K #4099 / #4100 / #4104.

### MCP OAuth — token/registration endpoints not SSRF-validated (#3623)

`parse_authorization_server_metadata` already ran a literal
`is_ssrf_blocked_host` check against discovered endpoints, but:

* `is_ssrf_blocked_url` did not reject userinfo-bearing URLs, so
  `http://[email protected]/` would pass the host check
  while reqwest connected to the IMDS literal — same shape as #3527.
* `KernelOAuthProvider::register_client` POSTed to the
  registration endpoint with no SSRF re-check; the parser's check
  could be bypassed if the value reached `register_client` from a
  cached vault entry written before policy tightened.
* The API-layer auth-code exchange in `routes/mcp_auth.rs` POSTed
  to the stored `token_endpoint` from the vault with no re-check —
  the kernel `try_refresh` already had the matching guard.

Fix: tighten `is_ssrf_blocked_url` to also reject non-http/https
schemes and any URL with userinfo, then re-validate at every actual
outbound site (parser, register_client, auth-code exchange) so the
guard is uniform whether the value came from discovery or vault.

### Channels — attachment URLs fetched server-side without SSRF (#3442)

`bridge::download_file_to_blocks` and `download_image_to_blocks`
both validated only the URL scheme.  A forged inbound message could
smuggle `http://169.254.169.254/latest/meta-data/...` or
`http://127.0.0.1:4545/api/agents` and have the response base64'd
into the agent's LLM context.

Fix: route both paths through the existing
`http_client::validate_url_for_fetch` SSRF guard (same one the
generic webhook adapter uses), which rejects loopback / private /
link-local / unique-local / multicast / IPv4-mapped IPv6 / NAT64 /
internal hostnames.

### DingTalk — replay window too wide + silent-empty-secret (#3441)

The non-numeric-timestamp bypass was already closed (parser early
returns 400). Two remaining issues:

* Replay window was 1 hour — DingTalk signs with current millis,
  so anything wider than a few minutes is pure replay surface.
  Tightened to ±5 min.
* `read_token(secret_env).unwrap_or_default()` accepted an empty
  signing secret silently — verification would still reject (HMAC
  with empty key vs. a real signature never matches), but the
  operator got no signal.  Now refuses to register the adapter
  with a loud `error!` log when the secret env is unset or empty,
  matching the Teams default-deny shape from #4100.

Closes #3623
Closes #3442
Closes #3441

* fix(ssrf,channels,mcp): close 3 followup safety gaps

Three independent inbound-side / outbound-side input-safety bypasses
batched into one PR per request, following PR-K #4099 / #4100 / #4104.

### MCP OAuth — token/registration endpoints not SSRF-validated (#3623)

`parse_authorization_server_metadata` already ran a literal
`is_ssrf_blocked_host` check against discovered endpoints, but:

* `is_ssrf_blocked_url` did not reject userinfo-bearing URLs, so
  `http://[email protected]/` would pass the host check
  while reqwest connected to the IMDS literal — same shape as #3527.
* `KernelOAuthProvider::register_client` POSTed to the
  registration endpoint with no SSRF re-check; the parser's check
  could be bypassed if the value reached `register_client` from a
  cached vault entry written before policy tightened.
* The API-layer auth-code exchange in `routes/mcp_auth.rs` POSTed
  to the stored `token_endpoint` from the vault with no re-check —
  the kernel `try_refresh` already had the matching guard.

Fix: tighten `is_ssrf_blocked_url` to also reject non-http/https
schemes and any URL with userinfo, then re-validate at every actual
outbound site (parser, register_client, auth-code exchange) so the
guard is uniform whether the value came from discovery or vault.

### Channels — attachment URLs fetched server-side without SSRF (#3442)

`bridge::download_file_to_blocks` and `download_image_to_blocks`
both validated only the URL scheme.  A forged inbound message could
smuggle `http://169.254.169.254/latest/meta-data/...` or
`http://127.0.0.1:4545/api/agents` and have the response base64'd
into the agent's LLM context.

Fix: route both paths through the existing
`http_client::validate_url_for_fetch` SSRF guard (same one the
generic webhook adapter uses), which rejects loopback / private /
link-local / unique-local / multicast / IPv4-mapped IPv6 / NAT64 /
internal hostnames.

### DingTalk — replay window too wide + silent-empty-secret (#3441)

The non-numeric-timestamp bypass was already closed (parser early
returns 400). Two remaining issues:

* Replay window was 1 hour — DingTalk signs with current millis,
  so anything wider than a few minutes is pure replay surface.
  Tightened to ±5 min.
* `read_token(secret_env).unwrap_or_default()` accepted an empty
  signing secret silently — verification would still reject (HMAC
  with empty key vs. a real signature never matches), but the
  operator got no signal.  Now refuses to register the adapter
  with a loud `error!` log when the secret env is unset or empty,
  matching the Teams default-deny shape from #4100.

Closes #3623
Closes #3442
Closes #3441

* fix(quality): cargo fmt #4110 mcp_oauth_provider.rs + mcp_oauth.rs

* docs(mcp-oauth): correct userinfo-guard rationale

The original doc/test comments claimed `host_str()` returns "allowed.com"
for `http://[email protected]/`, implying the host check was
bypassed.  Verified with the `url` crate (RFC 3986 compliant): host_str()
returns `169.254.169.254` — the IMDS literal — so that URL is already
caught by `is_ssrf_blocked_host`.

The userinfo guard is still worth keeping, but for a different reason:
phishing-shape inputs like `http://[email protected]/` where the
post-`@` host is legitimate and only the userinfo guard rejects.  That
case is also the unique regression point for the new test — flagged
inline so a future refactor that drops the guard will see exactly which
assertion fails.

* fix(ssrf,dingtalk): address review comments from #4110

- mcp_oauth_provider: replace bare reqwest::Client::new() with
  librefang_extensions::http_client::new_client() in both try_refresh
  and register_client so redirect limits and timeouts apply on the
  post-SSRF-check outbound requests.
- dingtalk: change REPLAY_WINDOW_MS to u64 and use saturating_sub
  before unsigned_abs to prevent i64 overflow on a forged extreme
  timestamp; cast eliminated since both sides are now u64.
- channel_bridge: remove duplicate secret_env from the error! format
  string — the value is already captured as a structured field via
  env = %dt_config.secret_env.

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>