AUTH4D-216 Webhook application filters and event coverage

This fragment extends AUTH4D-157 (repository file docs/api-spec/auth4d-157.md). Webhook event bodies and the Standard Webhooks signature headers are unchanged. Storage adds the nullable application_id column in migration 0033_webhook_application_filter.sql.

Application filter

applicationId is optional on POST /management/tenants/{tenantId}/webhooks and PATCH /management/tenants/{tenantId}/webhooks/{endpointId}. It is a client id in the same project. Omit it or send null to receive events from every application; on PATCH, null clears an existing filter. An id from another project is answered as 404 not_found.

{
  "url": "https://game.example.com/hooks/auth4",
  "applicationId": "cli_0123456789abcdef",
  "eventTypes": ["user.created", "guest.upgraded", "session.revoked", "member.changed"]
}

Endpoint representations include applicationId, either a client id or null. The console offers an application selector and labels project-wide endpoints. When an endpoint is filtered to an application, an event with a different application_id does not match. Project-level member.changed events have application_id: null and go only to unfiltered endpoints.

Delivered event types

The five event types from AUTH4D-158 are delivered through the same best-effort queue path and signed with the endpoint’s existing secret:

All event types use webhook-id, webhook-timestamp and webhook-signature as before. Retries keep the same event id and body; the timestamp and signature are generated for each attempt.