GHSA-xxv7-2vv3-h682

### Summary A project member can create a webhook alert channel whose delivery URL points at an internal address, and trigger.dev's control plane will send the alert there with no SSRF protection. The webhook URL is stored as an unvalidated string and is fetched directly from the webapp server, so a low-privilege authenticated user can make the server issue POST requests to internal-only services and cloud metadata endpoints (for example http://169.254.169.254/). No private-IP, scheme, or redirect filtering exists anywhere in the webapp. ### Details The delivery sink performs a raw fetch to the stored URL, apps/webapp/app/v3/services/alerts/deliverAlert.server.ts:949 (#deliverWebhook): ```js const response = await fetch(webhook.url, { method: "POST", headers: { "content-type": "application/json", "x-trigger-signature-hmacsha256": signatureHex, }, body: rawPayload, signal: AbortSignal.timeout(5000), }); ``` The same pattern is in apps/webapp/app/v3/services/alerts/deliverErrorGroupAlert.server.ts:245. The URL is never validated. The stored shape is a bare string, apps/webapp/app/models/projectAlert.server.ts:6: ```js url: z.string(), // not even .url() ``` The public API that creates alert channels accepts it with no constraint, apps/webapp/app/presenters/v3/ApiAlertChannelPresenter.server.ts:35: ```js url: z.string().optional(), ``` and stores it (line 139-142). The dashboard create route applies only `z.string().url()`, which still accepts http://169.254.169.254/... and http://127.0.0.1/.... A repository-wide search for any SSRF guard (private-IP/link-local/loopback/metadata blocklist, DNS-rebinding re-check, request-filtering agent) in apps/webapp returns nothing, so no protection exists at any layer. Creating the alert channel only requires organization membership (the API path resolves the project via findProjectByRef, which requires `organization.members.some.userId`); no admin role is needed. ### PoC As any member of an organization (