notification/teams: add Microsoft Teams notification destination

[mageru]

• Identified the issue which this PR solves.
• Read the CONTRIBUTING document.
• Code builds clean without any errors or warnings.
• Added appropriate tests for any new functionality.
• All new and existing tests passed.
• Added comments in the code, where necessary.
• Ran make check to catch common errors. Fixed any that came up.

Description:
Adds Microsoft Teams as a first-party notification destination. Since Office 365 connectors were retired, the supported webhook-style path into Teams is a Power Automate Workflow webhook ("Post to a channel when a webhook request is received"). This PR adds a builtin-teams-workflow destination type that renders GoAlert notifications as Adaptive Cards and posts them to such a webhook.

• New notification/teams package implementing nfydest.Provider and nfydest.MessageSender, following the existing notification/webhook and notification/slack patterns.
• Adaptive Cards (schema 1.2, the conservative version Teams supports through workflow webhooks) for alert notifications, alert status updates, alert bundles, schedule on-call notifications, universal-key signal messages, and test messages. Alert cards are colored by state (Attention/Warning/Good) to match the Slack color scheme, include service name and truncated details, and carry an "Open Alert" button that deep-links into GoAlert.
• Error classification in the sender: 429/5xx responses are retried, other 4xx and disallowed URLs fail permanently.
• Status updates are posted as new cards (workflow webhooks cannot edit previously posted messages).
• /docs gains a "Microsoft Teams" section (shown when Teams is enabled) with setup steps for creating the workflow webhook.

Which issue(s) this PR fixes:
N/A — no associated issue.

Out of Scope:
Interactive Ack/Close buttons inside Teams cards. Microsoft does not deliver card actions back to the sender for workflow-webhook posts; that requires a Bot Framework integration (bot registration, conversation reference storage, inbound activity endpoints, and identity linking). The card renderer is structured so a future bot-backed sender can reuse it and add Action.Execute buttons.

Screenshots:
N/A

Describe any introduced user-facing changes:

• New admin config settings: Teams.Enable and Teams.AllowedWorkflowURLs (optional domain allow-list, mirroring Webhook.AllowedURLs).
• When enabled, a "Microsoft Teams" destination becomes available for escalation policy steps, schedule on-call notifications, and universal integration key actions, with a required "Workflow Webhook URL" field (https-only, validated against the allow-list).
• New Teams icon for destination chips and a "Microsoft Teams" section on the /docs page.

Describe any introduced API changes:

• New destination type builtin-teams-workflow with required field teams_webhook_url and dynamic param message, exposed automatically through the existing destinationTypes GraphQL API.
• New config keys Teams.Enable and Teams.AllowedWorkflowURLs in the config GraphQL API.

Additional Info:
Unit tests cover card rendering per message type, details truncation, URL validation, error classification, and display info. A smoke test (test/smoke/teamsworkflow_test.go) verifies alert → ack → close card delivery end-to-end; it compiles cleanly but was authored on a Windows machine without a local Postgres, so it has not been executed locally — please let CI validate it. make check was likewise not run locally (Windows); Go vet, gofmt, go test ./notification/... ./graphql2/... ./config/... ./app/..., TypeScript typecheck, eslint, and prettier all pass.