feat: add Hazel as an alert destination type

[Makisuo]

Summary

• Adds a dedicated "hazel" destination type alongside slack / pagerduty / webhook so Maple alerts can be delivered into a Hazel chat channel.
• Reuses the existing buildPayload() JSON unchanged — Hazel parses Maple's standard webhook payload directly, so there's no parallel schema to maintain.
• Surfaces "Hazel" in the destination picker with a webhook URL field and helper text pointing at the matching Hazel setup screen.

Changes

Domain / contract (packages/domain/src/http/alerts.ts)

• Extend AlertDestinationType literal with "hazel".
• Add HazelAlertDestinationConfig and UpdateHazelAlertDestinationConfig.
• Add hazel variant to AlertDestinationCreateRequest and AlertDestinationUpdateRequest (fields: webhookUrl, optional signingSecret, optional enabled).

API services

• AlertDestinationHydration.ts — add hazel arm to DestinationSecretConfigSchema (mirrors webhook shape with a renamed URL key).
• AlertsService.ts — wire hazel through buildPublicConfig, buildSecretConfig, and the update-destination switch (preserving the existing url/secret on partial updates).
• AlertDeliveryDispatch.ts — add hazel case to the exhaustive Match dispatch. POSTs the existing payloadJson with x-maple-event-type, x-maple-delivery-key, and (when configured) an HMAC x-maple-signature header.

Web

• destination-dialog.tsx — Hazel option in the type picker plus conditional fields (Hazel webhook URL + optional signing secret) with helper copy.
• form-utils.ts — hazelWebhookUrl field on DestinationFormState, Hazel label, and create/update payload builders for the new type.

Reviewer notes

• Existing AES-256-GCM secret encryption path is unchanged — hazel flows through the same encrypt/decrypt as the other types.
• The dispatch test endpoint (POST /destinations/:id/test) automatically works for Hazel destinations via the same code path; the synthetic test payload is just eventType: "test" through buildPayload.
• The companion Hazel-side change (the /maple webhook receiver, embed builder, and integration UI) is in a separate PR on the Hazel repo.
• No DB migration: the existing alertDestinations table holds the hazel destination just like any other type.

Test plan

• bun typecheck passes (verified locally — 17/17 packages).
• In the running Maple web app, navigate to Alerts → Destinations → New destination → pick Hazel, paste a …/webhooks/incoming/{id}/{token}/maple URL from Hazel, and save.
• Hit Test on the destination → expect success: true with responseCode: 200 and providerMessage: "Delivered to Hazel".
• Trigger (or simulate) a real rule with the Hazel destination attached and confirm the rendered embed in the Hazel channel for both trigger and resolve events.
• Edit an existing Hazel destination, leave the URL field blank, and confirm the stored URL is preserved (partial-update path).

🤖 Generated with Claude Code