feat(filters): report custom-filter outcome reason for inbound filters

[shellmayr]

• Report custom-filter reason in outcomes for the new inbound filters v2
• This is for global tracking; the per-filter tracking is probably a separate mechanism, can we use outcomes for this as well?

Contributes to TET-2842

[linear-code]

TET-2842

[sentry-warden]

RuleCondition evaluation in generic/custom filters lacks recursion depth bound

RuleCondition::matches recurses through nested And, Or, Not, Any, and All variants without a depth limit. When a project config contains a deeply nested custom or generic filter condition, evaluating it against an event via should_filter can trigger a stack-overflow abort.

Evidence

• relay-filter/src/generic.rs line ~55: should_filter iterates over generic/custom filter configs and calls matches(item, filter_config.condition).
• relay-filter/src/generic.rs line ~31: matches delegates to RuleCondition::matches, entering the recursive sink.
• relay-protocol/src/condition.rs lines ~790-802: RuleCondition::matches dispatches to AndCondition::matches, OrCondition::matches, NotCondition::matches, AnyCondition::matches, and AllCondition::matches with no depth guard or visited-set.
• The RuleCondition trees are deserialized from upstream project-configuration JSON (including new custom filters prefixed with cif-); Relay enforces a 20 MB total response size cap but no nesting-depth validation before evaluation.
• No sibling depth-bounded equivalent exists for this evaluation path.

_{Identified by Warden · wrdn-dos-review · 48Z-6E5}