feat: Add folderUid support

[VikaCep]

Add folderUid support to checks

Part of https://github.com/grafana/synthetic-monitoring/issues/589

Adds support for the folderUid field on checks, allowing checks to be associated with a specific Grafana folder.

Why

The SM API now returns and accepts a folderUid field on checks. This field is API-only, it is intentionally not part of the protobuf definition to avoid propagating it to probes.

What changed

• model.Check — New wrapper type that embeds synthetic_monitoring.Check and adds FolderUid. This is the same pattern CheckWithAlerts already used for extending the proto type with API-only fields.
• Tests — Updated check tests to verify folderUid round-trips correctly through add, get, update, list, list-with-alerts, and query.

Check client methods now use model.Check instead of synthetic_monitoring.Check.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[vmgrlab]

@VikaCep is this still relevant ?

This is a breaking change in public API, are we ok with that ? On example this method is used here https://github.com/grafana/terraform-provider-grafana/blob/85533e88d30360a0617d0a44dc165f36c0aff4fc/internal/resources/syntheticmonitoring/resource_check.go#L848

[mem]

@VikaCep is this still relevant ?

This is a breaking change in public API, are we ok with that ? On example this method is used here grafana/terraform-provider-grafana@85533e8/internal/resources/syntheticmonitoring/resource_check.go#L848

There's no way around it. I think our best bet right now is to simply accept the breakage, but we need to do it once, we cannot do piecemeal updates and break this multiple times. My take is that we take the OpenAPI spec we generate in the API (which is public) and we generate the client from that.

[VikaCep]

@mem @vmgrlab

Yes, this is still relevant. The API-side PR (grafana/synthetic-monitoring-api#2023) is already merged, so it accepts and returns folderUid today. The terraform provider PR (terraform-provider-grafana#2650) is ready and waiting on this.

I understand the concern about breaking the public API more than once. So what would you say is the preferred path forward?

• Ship this first. Accept the one-time breakage to model.Check, ship folderUid support in the terraform provider soon, and track the OpenAPI client generation as a separate follow-up.
• Do the full OpenAPI spec migration first. generate the client from the API's OpenAPI spec so we only break things once, but pause terraform folderUid support until that migration is complete.

I'm happy to go either way, but I don't have a good sense of how much time/effort the OpenAPI migration would take. Any thoughts on scope and timeline for that?

[vmgrlab]

I understand the concern about breaking the public API more than once. So what would you say is the preferred path forward?

• Ship this first. Accept the one-time breakage to model.Check, ship folderUid support in the terraform provider soon, and track the OpenAPI client generation as a separate follow-up.
• Do the full OpenAPI spec migration first. generate the client from the API's OpenAPI spec so we only break things once, but pause terraform folderUid support until that migration is complete.

I'm happy to go either way, but I don't have a good sense of how much time/effort the OpenAPI migration would take. Any thoughts on scope and timeline for that?

I think we can merge this and update deps this time. Additionally we can create an issue to migrate some existing code here to auto-generated from OpenAPI spec.