Follow-up to #33817 / #33821

#33821 fixed the reported bug (a `CustomGuardrail` blocking via `HTTPException(403)` or `(422)` showed as "Flagged" instead of "Blocked" in the Guardrail Monitor) by widening `CustomGuardrail._is_guardrail_intervention()` from `status_code == 400` to an explicit allowlist `{400, 403, 422}`. That is deliberately narrow so propagated upstream statuses (401 bad key, 408 timeout, 429 rate limit) stay `guardrail_failed_to_respond`

The narrowing is a point fix. Classifying a guardrail's intent from the HTTP status the author happened to pick is fragile, and an exhaustive audit of the raise sites during review surfaced pre-existing gaps that #33821 does not change. This issue tracks the durable fix and those gaps

## Durable fix: explicit block marker

Instead of inferring intent from the status code, guardrails should signal a deliberate block explicitly (for example `GuardrailRaisedException`, or a pre-recorded StandardLoggingGuardrailInformation entry with a block status) and `_is_guardrail_intervention()` should key off that marker. This removes the status-code guessing entirely and is backward compatible with the current allowlist during migration

The …