fix(testdata): unblock e2e fresh creates for webhooks and audit_logs logpush

[vaishakdinesh]

Summary

The e2e workflow has been failing since ~May 12 because prior "green" runs were
no-op refreshes against pre-existing state. When state was destroyed and CI
started attempting fresh creates, two long-latent testdata bugs surfaced:

1. notification_policy_webhooks (22 errors per run)

Testdata used https://www.cloudflare.com/cdn-cgi/trace as the webhook URL.
That endpoint accepts GET (returns 200) but Cloudflare's Notifications API
does a POST to validate webhooks on create — and gets 4xx back. All
terraform apply create calls fail with:

error connecting webhooks destination <name>: Webhook test failed with status code 403 403 Forbidden

Verified directly against the Notifications API:

POST /accounts/<acct>/alerting/v3/destinations/webhooks
{ "url": "https://www.cloudflare.com/cdn-cgi/trace" }
→ 403

Switching to https://httpbin.cfdata.org/post succeeds:

POST /accounts/<acct>/alerting/v3/destinations/webhooks
{ "url": "https://httpbin.cfdata.org/post" }
→ 200

2. logpush_job with dataset audit_logs (2 errors per run)

The testdata's audit_logs jobs used ClientIP / EdgeStartTimestamp in
field_names and logpull_options. Those are http_requests dataset fields,
not audit_logs. The API rejects the create:

error creating logpush job for audit_logs dataset:
no valid fields for dataset audit_logs: none of the requested fields exist in the schema (1004)

The current audit_logs schema fields (from the datasets API) are:
ActionResult, ActionType, ActorEmail, ActorID, ActorIP, ActorType, ID, Interface, Metadata, NewValue, OldValue, OwnerID, ResourceID, ResourceType, When.

Testdata updated to use ActorEmail, ActionType, When.

Why this only started failing now

The pre-existing v4-provider create-time checks never fired while state was
intact from earlier successful applies — every subsequent run was a no-op
refresh. Once state and reality diverged (out-of-band deletions, state wipes),
CI had to recreate from scratch and immediately hit these two latent issues.

Verification

• go test ./integration/... -run TestV4ToV5Migration/notification_policy_webhooks — pass
• go test ./integration/... -run TestV4ToV5Migration/logpush_job — pass
• go test -race ./integration/... (full suite) — pass
• Webhook create with new URL via direct Notifications API call — success
• audit_logs field list confirmed via GET /accounts/<acct>/logpush/datasets/audit_logs/fields

Not in this PR

• custom_hostname JSON parse errors — still present in e2e (~5 errors).
  Provider gets non-JSON when creating a Custom Hostname cert. Needs separate
  investigation; may be a v4 provider bug or flaky Custom Hostnames endpoint.

[vaishakdinesh]

Added workflow split (commit e4327d1):

• e2e-tests.yml (blocking on main push): now pins provider to v${TARGET_PROVIDER_VERSION} (currently 5.21.1). Single-source var used both for provider checkout ref and --target-provider-version flag.
• e2e-tests-next.yml (new, manual): builds provider from next (or any user-supplied ref/SHA). Advisory — failures don't block main.

Same concurrency group so they can't clash on the shared test account.

Important compatibility note

v5.21.1 does not yet include the state-upgrader fixes from cloudflare/terraform-provider-cloudflare#7236 (ruleset asset_name, load_balancer_pool flatten_cname). If we merge this workflow change as-is, main CI will still fail with the same 51 errors that PR #7236 addresses.

Two ways forward once PR #7236 is merged upstream:

1. Wait for the next stable v5 release (v5.21.2 or v5.22.0) that carries #7236, then bump TARGET_PROVIDER_VERSION in a one-line PR.
2. Or temporarily set TARGET_PROVIDER_VERSION to a commit SHA on the provider next branch that has #7236, until a release ships.

Either way the merge order matters: land provider PR #7236 first, then merge this tf-migrate PR (with the appropriate pin), so main CI is green from the moment this ships.