Security: SSRF via unvalidated webhook and integration URLs in the management API

### Summary
Multiple management API endpoints accept an attacker-controlled absolute URL (e.g. `url`, `base_url` on webhooks and third party integrations such as Dynatrace / Datadog / New Relic) and persist it with no allow list, scheme restriction, DNS resolution check, or internal network deny list at the application layer. When a feature flag state later changes, the task processor issues an outbound request to that stored URL from inside the deployment's network. This is a server-side request forgery (SSRF) vector.

Combined with open self registration (`ALLOW_REGISTRATION_WITHOUT_INVITE=True`, which mints an active session), the chain can be driven end to end by an unauthenticated external actor.

### Steps to reproduce
1. `POST /api/v1/auth/users/` to create an account (open registration mints an active session).
2. Create an organisation, project and environment.
3. Register a webhook or a Dynatrace / Datadog / New Relic integration whose URL points at an internal or attacker controlled host.
4. Toggle a feature flag to trigger the server-side request.

Trace the management API endpoints that persist webhook, Dynatrace, Datadog, and New Relic URLs, then follow the task processor path triggered by feature-flag changes. Review the open-registration flow as part of the reported attack chain. Done means unsafe or internal destinations are rejected before persistence or outbound requests, with coverage for the affected integrations and registration path.

Written by the indexing model from the issue text.