Validation: Update InlineValidatorTypeEnum #1270

Describe the bug
InlineValidatorTypeEnum (backend/app/models/llm/request.py) gates which type values an inline validator spec in config_blob.input_guardrails / output_guardrails may use. It drifted from the tenant catalogue returned by GET /api/v1/guardrails (EXPOSED_VALIDATOR_TYPES in backend/app/services/llm/guardrails.py):

• enum allows profanity_free, which the catalogue no longer exposes
• enum rejects uli_slur_match, which the catalogue exposes and which is the primary slur check

Two hand-maintained lists for the same set (PR #1245 vs #1257) is what let them diverge.

Expected behavior
Inline validator type accepts exactly the types GET /guardrails lists: gender_assumption_bias, uli_slur_match, pii_remover, topic_relevance_llm. One source of truth for both.

Steps to reproduce

1. GET /api/v1/guardrails on staging — uli_slur_match is listed, profanity_free is not.
2. POST /llm/call with input_guardrails: [{"type": "uli_slur_match"}] — 422, type not in enum.
3. Same with {"type": "profanity_free"} — accepted, but the type is not productised.

Proposed fix
Swap profanity_free for uli_slur_match in InlineValidatorTypeEnum; derive EXPOSED_VALIDATOR_TYPES from the enum. Fixed in #1269.

Original issue

create a PR to update this as validators for now have changed … remove profanity_free and add slur_list updated one