Add environments attribute to the logfire_alert resource

[Viicos]

Related Issue

N/A (requested directly: allow scoping an alert to specific deployment environments from IaC, alongside frequency/time_window).

Description

Adds an optional environments attribute (set of strings) to the logfire_alert resource, mapped to the environments field the Logfire alerts API already accepts on create/update and returns on read. This lets IaC users write, for example:

resource "logfire_alert" "example" {
  # ...
  frequency    = "10m"
  time_window  = "10m"
  environments = ["production", "staging"]
}

(and equivalently environments: ["production"] through the bridged Pulumi provider.)

Design decisions:

• Set, not list: ordering is not meaningful to the API, so a set avoids ordering-only diffs, matching the existing channel_ids attribute.
• Null vs empty round-tripping: the API returns environments: [] for an unfiltered alert. To keep an omitted attribute stable, alertReadToModel keeps the attribute null when the API returns an empty list and the config omitted it (same approach the resource already uses for description). A configured empty set is preserved as an empty set; both mean "all environments".
• Clearing on update: removing the attribute from config sends environments: [] on update so the server-side filter is actually cleared, rather than silently left in place.

Testing: new unit tests cover the create/read mapping (null, empty, and populated); the alert acceptance test gains steps that set environments, verify state, then remove the attribute and verify it returns to null. go build, go test ./..., gofmt, go vet, and golangci-lint run all pass; docs were regenerated with make generate (tfplugindocs).

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

The change is additive and safe to revert: alerts created with environments keep their server-side filter, and a reverted provider simply stops managing that field.

Changes to Security Controls

No. This adds an optional filtering attribute to an existing resource; no changes to access controls, encryption, or logging.

🤖 Generated with Claude Code

https://claude.ai/code/session_019M73jzqCewwcc6pmvVWPeg

---

Generated by Claude Code

[Viicos]

Status note on the red acceptance-test checks: both matrix jobs (1.8., 1.14.) fail only on TestAccSloResource, which is pre-existing and unrelated to this PR. The SLO create API now requires scope_kind and scope_value (added in platform PR #26866, "Add out-of-the-box SLOs for LLM providers"), and the provider's SloCreate payload still sends only service_name, so the API rejects it with a 422 (Field required: scope_kind / scope_value). This fails on main too and needs a follow-up to the logfire_slo resource.

Everything in this PR's scope is green on the latest commit: TestAccAlertResource (including the new environments set/unset steps), TestAccAlertResourceOmittedDescription, the unit tests, lint, and the generate check.

---

Generated by Claude Code