Zaraz Facebook Pixel sends mapped PII source values alongside hashed Meta user_data

Nobody has claimed this yet.

### What is the error message?
Meta Events Manager reports that the original plaintext source field for a mapped customer-information value is reaching the dataset as an event parameter, alongside the hashed Meta `user_data` field sent by Facebook Pixel / Conversions API.

### What is the issue or error you're encountering
Mapped PII/customer-information fields appear to be sent twice: hashed in Meta `user_data` and again as original plaintext event/custom parameters.

### What steps have you taken to resolve the issue?
In a Cloudflare Zaraz Facebook Pixel tool configuration, Facebook customer-information fields can be mapped from event properties. Examples include mapping an event property to Meta's Email / `em`, First Name / `fn`, Last Name / `ln`, Phone / `ph`, City / `ct`, State / `st`, Zip / `zp`, Country / `country`, or External ID / `external_id`.

The expected behavior is that Zaraz uses each mapped source property only to populate the corresponding Meta customer-information field. These fields are handled by the Facebook integration as `user_data`; several of them are normalized/hashed before being sent to Meta. The original source property should not also be sent as a raw event parameter.

The observed behavior is that Meta can still report the original plaintext source property as an event parameter reaching the dataset via CAPI, while the corresponding Meta destination key is also handled as `user_data`. This suggests that the mapped source field is not being consumed or removed from the payload before the remaining event payload is forwarded as Facebook event/custom parameters.

This is privacy-sensitive because the visible Zaraz configuration makes it look like the source property is handled as a Facebook customer-information field, while Meta flags the original source alias as a raw event parameter that may contain PII.

The durable behavior I would expect is:

- Field mappings are applied per tool/action.
- A source field mapped to a sensitive Facebook customer-information destination is marked as consumed for that specific Facebook Pixel action.
- Consumed source fields are excluded from generic event/custom parameters sent to that same component endpoint.
- Only explicitly intended event parameters remain eligible for Facebook `custom_data`.

Public source-code context for why this can happen:

- The public Facebook Pixel managed component recognizes Meta user-data keys such as `em`, `ph`, `fn`, `ln`, `ct`, `st`, `zp`, `country`, and `external_id`: https://github.com/managed-components/facebook-pixel/blob/v1.0.13/src/track.ts#L4-L18
- It hashes recognized keys when configured that way, writes them to `body.user_data`, and deletes those exact keys from the payload: https://github.com/managed-components/facebook-pixel/blob/v1.0.13/src/track.ts#L124-L138
- It then forwards the remaining payload as `custom_data`: https://github.com/managed-components/facebook-pixel/blob/v1.0.13/src/track.ts#L144-L144

So if Zaraz maps a custom source property to a Meta user-data key but leaves the original plaintext source property in the component payload, the component can hash/delete the Meta destination key correctly while the original source field still remains eligible for custom/event data.

Can Cloudflare confirm whether mapped source fields are supposed to be consumed before Facebook Pixel event parameters are built? If not, is there a supported way to map event properties to Facebook customer-information fields without also sending the original source properties as event parameters?

- Confirmed the Facebook Pixel tool maps customer-information fields from event properties.
- Confirmed Meta Events Manager reports a mapped source property as a blocked/action-required event parameter for affected events.
- Reviewed the public `managed-components/facebook-pixel` source at `v1.0.13`, which hashes and deletes exact Meta user-data keys, then forwards remaining payload keys as `custom_data`.
- Reviewed the public WebCM reference implementation. It passes event payloads into component listeners and does not expose a public mapping-consumption step that would tell the Facebook component which original source fields were mapped to Meta user-data fields.
- Searched public GitHub issues/PRs and Cloudflare Community-visible results for this Zaraz / Facebook Pixel / mapped customer-information CAPI warning pattern and did not find a matching public report.

### What are the steps to reproduce the issue?
1. Configure Cloudflare Zaraz with the Facebook Pixel tool and server-side Conversions API access token.
2. In the Facebook Pixel tool settings, map one or more Facebook customer-information fields from custom event properties. For example, map Email / `em` from a custom source property, or map First Name / `fn`, Last Name / `ln`, Phone / `ph`, location fields, or External ID from custom source properties.
3. Send a Zaraz event whose payload includes the mapped source property, plus a normal event name and event ID.
4. Let Zaraz send the event to Meta through Facebook Pixel / CAPI.
5. Open Meta Events Manager for the dataset.
6. Check blocked/action-required event parameters.
7. Observe that the original mapped source property can appear as an event parameter, even though it is mapped to a Facebook customer-information field.

Expected result: the mapped source property is consumed by the Facebook customer-information mapping and does not appear as a raw event parameter/custom data field for the Facebook Pixel request.

Actual result: Meta reports the mapped source property as an event parameter reaching the dataset via CAPI.

### Reference
* https://community.cloudflare.com/t/zaraz-facebook-pixel-sends-mapped-pii-source-values-alongside-hashed-meta-user-data/939515
* https://github.com/cloudflare/webcm/issues/119

Start in src/track.ts, especially the Meta user_data handling around lines 4-18 and 124-144. Trace how mapped source properties enter the component payload and how remaining fields become custom_data, then compare the WebCM behavior referenced in issue 119. Done means mapped source fields no longer appear as raw event parameters for the same Facebook Pixel request.

Written by the indexing model from the issue text.