Fix SSRF/credential forwarding via client-supplied baseUrl

[Wing900]

问题：当前实现允许客户端传入 baseUrl，同时在未提供 apiKey 时会回退使用服务器环境变量 key，导致服务器可能携带自己的 key 请求攻击者控制的地址（凭据泄露/SSRF）。

修复：禁止 ‘server key + client baseUrl’ 组合：只要自定义 baseUrl，就必须显式提供客户端 key；生产环境增加 SSRF 校验，并对连通性检查禁用重定向。

EN：Description:
Currently, the system allows clients to provide a custom baseUrl. If no apiKey is provided, it falls back to the server's environment variable, which could lead to API key leakage to attacker-controlled endpoints (Credential Leakage/SSRF).
Fixes: 1. Prohibit the combination of 'server-side key + client-provided baseUrl'. 2. Integrated SSRF validation in production environments. 3. Disabled redirects in connectivity checks to further mitigate SSRF risks.

[cosarah]

LGTM. 核心修复逻辑正确：

1. 禁止 server key + client baseUrl 组合 — 10 个路由全部覆盖，避免凭据泄露
2. SSRF 校验仅生产环境生效 — 合理，不影响本地开发
3. verify-pdf-provider 禁用 redirect — 该路由是唯一直接 fetch 的 verify 路由，其他 verify 路由由 SDK 控制，无需额外处理

已本地验证，功能正常。