[Security] Enforce SSRF validation for persisted AI provider base URLs #420

Summary

User-provided AI provider baseUrl values are persisted and used in runtime provider execution without SSRF validation on the main path.

Why this matters

External URL validation exists in model-discovery endpoints but is not enforced where requests are actually made for chat/provider execution.

Current behavior (evidence)

• Settings accept/store base URL with basic string sanitization:
  • apps/web/src/app/api/ai/settings/route.ts
  • apps/web/src/lib/ai/core/ai-utils.ts (createOllamaSettings, createLMStudioSettings)
• Runtime provider factory uses stored URLs directly:
  • apps/web/src/lib/ai/core/provider-factory.ts
• Model-discovery routes do call SSRF validation:
  • apps/web/src/app/api/ai/ollama/models/route.ts
  • apps/web/src/app/api/ai/lmstudio/models/route.ts

Risk / impact

Potential server-side request forgery in environments where users can set provider URLs and server can reach sensitive internal services.

Proposed remediation

• Enforce validateExternalURL (or safeFetch) at write-time and runtime-use-time.
• Define explicit policy for local/self-host scenarios (e.g., allowlist if private IPs are intended).
• Normalize and persist validated URL form only.
• Add tests for blocked metadata/private/internal targets.

Acceptance criteria

• Unsafe URLs are rejected on settings save.
• Runtime provider initialization also rejects unsafe URLs (defense in depth).
• SSRF regression tests cover localhost/private/link-local/cloud metadata endpoints.