Feature Request: Preserve EndsAt timestamp in Webhook payloads instead of resetting to zero value

Proposal

Description

I've noticed that Alertmanager explicitly resets the EndsAt field to a zero value (0001-01-01T00:00:00Z) when sending webhook payloads for alerts that are not yet resolved.

Technical Observation

The current logic specifically clears the EndsAt value as follows:

	for _, alert := range alerts {
		a := *alert
		// Ensure that alerts don't resolve as time move forwards.
		if a.ResolvedAt(now) {
			resolvedSlice = append(resolvedSlice, &a)
		} else {
			a.EndsAt = time.Time{}
		}
		alertsSlice = append(alertsSlice, &a)
	}

Question & Curiosity

I found that this behavior has been discussed in several previous issues:

• https://github.com/prometheus/alertmanager/issues/3351
• https://github.com/prometheus/alertmanager/issues/3341

Since these discussions have been around for a while without a change in the implementation, I’m curious if there’s a specific technical reason or a design philosophy behind keeping this as a zero value. Is this behavior intentionally maintained to avoid specific side effects that I might be overlooking? Or is there a concern that exposing this value might lead to inconsistent states in external integrations?

Start by tracing the webhook payload construction loop shown in the issue and read the linked discussions in issues 3351 and 3341. Determine the intended semantics for EndsAt on unresolved alerts and confirm the change does not cause alerts to resolve as time advances; done requires an agreed behavior and corresponding webhook coverage.