### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When a `generic_guardrail_api` guardrail blocks a request (returns `action: "BLOCKED"`), the `log_guardrail_information` decorator misclassifies the block as `guardrail_failed_to_respond` instead of `guardrail_intervened`.

This causes the Guardrails Monitor dashboard to show **0 blocked requests** and **100% pass rate** even when blocks are actively occurring.

### Steps to Reproduce

## Root Cause

`_is_guardrail_intervention()` in `litellm/integrations/custom_guardrail.py` only recognizes two exception types as intentional blocks:

```python @staticmethod def _is_guardrail_intervention(e: Exception) -> bool: if isinstance(e, ModifyResponseException): return True if (HTTPException is not None and isinstance(e, HTTPException) and e.status_code == 400): return True return False ```

But `generic_guardrail_api.py` raises `GuardrailRaisedException` on block — which is **not checked** by `_is_guardrail_intervention`. So `_process_error` falls through to `guardrail_failed_to_respond`.

## Expected Behavio…