feat(datadog-cr-validate): validate DatadogDashboard resources against the Datadog API #156

What

Follow-up to #154. Extend the datadog-cr-validate reusable workflow so DatadogDashboard resources get the same Datadog API validation that DatadogMonitor resources already get:

uses: DND-IT/github-workflows/.github/workflows/datadog-cr-validate.yaml@datadog-cr-validate

Current state

• DatadogMonitor: CRD schema check (kubeconform), then validated against Datadog with POST /api/v1/monitor/validate (actions/datadog-cr-validate/validate.py, monitors()).
• DatadogDashboard: CRD schema check plus a local lint only (validate.py, dashboards()): spec.widgets parses as a JSON array, every widget has a definition.type, and every template variable it uses is declared. Widget metrics feed the optional check_tag_values check.

Nothing checks a dashboard against Datadog itself. A widget with an invalid query, an unknown widget type, a bad layout, or a field Datadog rejects passes CI and only fails once the Datadog Operator tries to sync it.

Why it matters

Dashboards-as-code break silently: the CR applies fine in Kubernetes and the failure only shows up in the operator status, after merge.

Suggested approach

• Add a dashboards API step in validate.py and action.yaml, next to the existing "Validate monitors with the Datadog API" step, reusing the same keys and gating.
• Build the dashboard payload from the CR spec the way the operator does (title, layoutType, widgets, templateVariables, etc.), similar to monitor_payload().
• Datadog has no documented dry-run endpoint for dashboards that we know of; verify the options before picking one, e.g. per-widget validation if an endpoint exists, or create-then-delete a dashboard with a clearly marked title in a sandbox org.
• Add a test case to _test-datadog-cr-validate.yaml with a valid dashboard and one Datadog rejects.
• Update docs/workflows/datadog-cr-validate.md.