dotAI: Add rate limiting / abuse controls to /api/v1/ai/* endpoints

Note: Part of the dotAI security review.

Description

The dotAI REST endpoints (/api/v1/ai/completions, /completions/rawPrompt, /text/generate, /image/generate, /search) have no rate limiting, quota, or concurrency cap. Per-request maxTokens is bounded, but request rate is not. This exposes customers to:

• Denial of wallet — an authenticated user (or, where AI viewtools are placed on public/anonymous pages, an unauthenticated visitor) can loop requests and run up provider token/image costs.
• Resource exhaustion / DoS — the AI thread pool and provider quota can be saturated.

dotCMS should ship the enforcement hook (reuse existing dotCMS rate-limiting infrastructure) with sensible, config-overridable defaults. The customer retains responsibility for setting policy numbers, provider-side spend caps, and deciding whether AI runs on anonymous pages.

Affected code

• com.dotcms.ai.rest.CompletionsResource, TextResource, ImageResource, SearchResource.

Acceptance Criteria

• A per-user (and per-IP for anonymous) rate limit + concurrency cap is enforced on the dotAI REST endpoints.
• Limits reuse existing dotCMS rate-limiting infrastructure where available.
• Defaults are sensible and overridable via configuration (documented keys).
• Exceeding a limit returns a clear 429-style response, not a 500 or a silent drop.
• Integration test: a burst above the configured limit is throttled; normal usage is unaffected.
• Documentation notes the customer-owned responsibilities (spend caps, not exposing AI viewtools on anonymous pages).

Priority

Medium

Additional Context

Least coupled to the RAG/permission theme of the other issues; can be scheduled independently. Ties into the shared-responsibility guidance in the dotAI trust-boundary documentation.

Start by reading com.dotcms.ai.rest.CompletionsResource, TextResource, ImageResource, and SearchResource, then trace the existing dotCMS rate-limiting infrastructure. Verify how configuration keys and anonymous requests are handled before defining the integration-test setup. Done means per-user or per-IP limits and concurrency caps return a clear 429-style response, with documented defaults and customer responsibilities.