Reconsider strict validation of empty custom_headers in webhook destinations

[alexluong]

Context

Both CreateDestination and DestinationSettings in the portal have special-case logic to handle empty custom_headers for webhook destinations:

if (
  type.type === "webhook" &&
  key === "custom_headers" &&
  (configValue === "{}" || configValue === "")
) {
  configValue = "";
}

This feels off — the portal shouldn't need to call out a specific field for a specific destination type.

The question

In destwebhook.go, resolveConfig rejects an empty map ("{}") for custom_headers:

if len(config.CustomHeaders) == 0 {
    return nil, nil, destregistry.NewErrDestinationValidation(...)
}

But an empty map is semantically identical to the field being absent — both mean "no custom headers." The backend already handles absent/empty string by skipping the block entirely. Why not do the same for {}?

If the backend treated {} the same as absent, we could remove the workarounds in the portal entirely and the KeyValueMapField component wouldn't need any special empty-state handling.

Ref #707, #708, #674

[alexbouchardd]

Agreed instead of invalid input let's just ignore it, resulting in no custom_headers but also no validation error