Filtering query parameters / post processing

Is your feature request related to a problem? Please describe.
Filtering query params to ensure compliancy across multiple solutions.
We have multiple teams implementing the same tracker across multiple subdomains and would like to have some guardrails in place for all of these.

Describe the solution you'd like
We want to be able to process URLs from a central position (when events/context are being added, fx).
This could be scoped to allow post processing of any events or contexts.

Describe alternatives you've considered

• plugin with afterTrack implementation, mutating the Payload
• customFetch - mutating the Request with regexes
• implementing a custom PayloadBuilder - thanks to this we could manipulate the payload directly when it’s build - this is an optimal solution because we wouldn’t have to traverse the payload object twice - once when creating it and once when we want to filter and update query params in our events
• implementing custom Emitter - similar to option one, but tied directly to a tracker implementation and configuration

Additional context
The solution should also be aware of the context (fx. which namespace is this running for?)

The issue does not name files, tests, or an entry point. First clarify whether processing belongs at event/context creation, payload building, emitting, or request handling, and how namespace-aware filtering should be configured. Done should include an agreed central mechanism for URL query-parameter filtering across the tracker’s events or contexts.