Accept one Slack Events API delivery and fan it out to the triggers it fires.

The same pipeline as the per-trigger route, with the app in place of the trigger: resolve the registration, read a bounded body, verify Slack's signature with the registration's signing secret, rate-limit, and only then touch the database. Every refusal is the same 404.

Nothing is refused before the signature is checked. A registration id is an operator's chosen name, not a secret, and a budget spent before verification is keyed on the client address - which, behind a reverse proxy that is not trusted for X-Forwarded-For, is the proxy's, shared with Slack. Anyone who knew the Request URL could then exhaust it with unsigned requests and get every workspace's real deliveries refused. Verifying first costs a read of at most trigger_ingress_max_body_bytes and one HMAC-SHA256, and the budgets below are charged only for deliveries that verify.

What a failed request does spend is the per-client probing budget, and only to bound its audit rows: the audit queue is bounded and single-writer, so a flood of garbage must not crowd out real rows. Slack's own deliveries never fail verification and never touch it.