Pipeline security checks should follow SecurityClass

[liavweiss]

Description

Config-time security checks (failure_mode: open, request
conditions, SkipTo bypass) still match filter names against a
hardcoded SECURITY_FILTERS list in
filter/src/pipeline/checks.rs.

SecurityClass already exists on the registry. Builtins are
registered with register_http_security. Out-of-tree filters can
opt in with register_with_class(..., SecurityClass::Security).
The checks ignore that class, so a custom security filter is not
covered even when it is marked Security.

Make the registry class the source of truth and remove
SECURITY_FILTERS. Core must not list downstream filter names.

Tests

Keep existing builtin cases. Add:

• Custom filter, SecurityClass::Security, failure_mode: open
  → validation error.
• Same filter with allow_open_security_filters → no error.
• Custom filter, SecurityClass::Standard, failure_mode: open
  → no error.
• Custom Security-class filter with request conditions → error.
• SkipTo that jumps over a custom Security-class filter → error.

Motivation

A security filter with failure_mode: open skips the check on
timeout or other FilterError and forwards the request. Core
already refuses that for builtins. Out-of-tree filters (praxis-ai
credential_inject, later ai_guardrails) can register as
Security and still get no config-time warning.

Direction agreed in
discussion #1044:
honor SecurityClass in the checks; do not privilege core names
over external ones.

Acceptance criteria

• The three security checks use SecurityClass / is_security,
  not a name list.
• SECURITY_FILTERS is gone.
• Custom Security-class filters are covered by tests (fail-open,
  conditions, SkipTo).
• Builtin fail-open behavior is unchanged.
• Operator docs describe security-class filters, not a short
  builtin name list.