Feature: Add /v1/moderations endpoint

[SantiagoDePolonia]

Is your feature request related to a problem? Please describe.
GoModel does not implement the OpenAI-compatible /v1/moderations endpoint. Users evaluating GoModel as a single gateway for all their OpenAI-shaped workloads currently have to keep a separate tool around just for moderation checks.

Confirmed missing: there is no route, handler, or provider-side moderation call anywhere in the codebase (zero matches for moderation-related routes under internal/server/, and the route registration list in internal/server/http.go around lines 407-458 has no /v1/moderations entry).

Describe the solution you'd like
Add a /v1/moderations endpoint that accepts the standard OpenAI request shape (input as a string or array of strings, optional model) and returns the standard response shape (results with category flags and scores).

Realistically this ships as an OpenAI-only endpoint at first: no other provider already wired into GoModel (Anthropic, Gemini, xAI, Fireworks, Groq, etc.) exposes a comparable native moderation endpoint. Requests for providers without moderation support should get a clear, typed "unsupported for this provider" error rather than a confusing generic failure.

Describe alternatives you've considered
None - this is a small, additive endpoint with no real alternative shape to consider (the OpenAI moderation request/response format is simple and well established).

Additional context
Of the OpenAI-compatible endpoints GoModel is still missing, this is the simplest to add - closer in shape to the already-implemented /v1/embeddings (single small JSON request/response, no streaming, no multipart) than to chat/responses.

[nolanefe]

Hi, I’d like to work on this issue if it is still available.

I’ll follow the existing OpenAI-compatible endpoint patterns, using /v1/embeddings as the closest reference, and add:

• request and response types matching the OpenAI moderation shape
• a /v1/moderations route and handler
• OpenAI provider dispatch
• a clear typed error for providers that do not support moderation
• focused tests for string and string-array inputs, validation failures, successful responses, unsupported providers, and upstream errors

Before I begin, could you confirm whether you prefer unsupported providers to return the gateway’s existing provider-capability error format, or a moderation-specific error mapped to an OpenAI-compatible HTTP status?

I’m ready to trace the current route registration and provider interfaces and submit a focused PR.