List Builtin Guardrails

List the guardrails this gateway can run itself, for the form that defines one.

Every guardrail any_guardrail reaches over a hosted API, with the constructor and per-call arguments each one takes, so a guardrail is configured by picking it and filling typed fields. It is not the whole library: a guardrail that works by holding model weights in the process running it belongs in the guardrails service the profiles read beside this one describes, not here. A parameter names the environment variable that fills it where one exists, and requirement_groups carries the constraints satisfied by any of several parameters, which no single required flag can state. This is the counterpart of GET /api/v1/providers/catalog: the same picker, for a guardrail rather than a provider, and on the same gate that one takes.

Reaches no service, so there is no unavailable state to report: the answer is a property of the installed any_guardrail, not of any deployment's state.

On the catalog router rather than the operator one beside it, because the form this feeds belongs to an organization and is filled by an owner or admin, who reaches no operator route. So it is readable without deployment-wide standing, by a dashboard session and by any API key alike. What it publishes carries no deployment state to withhold: the same bytes on every deployment of the same build, and a parameter's environment variable is a name, never whether that name is set.

The profiles read next door keeps the stricter gate, and the difference is reach rather than audience. That one dials guardrails_url, so admitting a key there would let a workspace credential probe the deployment's own service. This one dials nothing.