fix(scrubber): redact sensitive query parameter mappings

[mhatipog]

Problem

EventScrubber.scrub_request() filters request.headers, request.cookies, and request.data, but omits request.query_string. The AWS Lambda integration populates that field as a mapping from queryStringParameters when the explicit data_collection configuration is not used. As a result, sensitive values under token / authorization / password remain in a captured event even though the same keys are covered elsewhere by the existing denylist.

This is a specific sensitive-data redaction gap, not a claim of a separately demonstrated remote exploit.

Fix

Reuse the existing scrub_dict and scrub_list on request.query_string:

• Filter default and custom denied keys in query parameter mappings, including case-insensitive names and list values.
• Preserve unaffected values and normal redaction metadata.
• Preserve existing raw URL-encoded query-string behavior unchanged (mapping-only fix), avoiding compatibility regressions and interference with data_collection.
• No new parser, dependency, or configuration.

Reproduction and tests

• Before: EventScrubber().scrub_event({"request": {"query_string": {"token": "SECRET"}}}) retains SECRET.
• After: the field contains [Filtered] and the standard !config redaction metadata.
• Added five upstream tests: sensitive mapping keys, custom denylist, raw-string compatibility, list-of-mappings, and a captured-event end-to-end test.
• A six-case local reproduction harness passes; also tested a full sentry_sdk.capture_event() path locally and verified both the filtered value and _meta.
• Upstream repository-wide CI is not yet validated: GitHub currently reports action_required for the forked PR workflows, which need maintainer approval to run.

Related to #4441's expectations for query parameter scrubbing, but does not close #4441 because that report concerns raw string query parameters; this fix addresses mappings (including AWS Lambda).

[sentrivana]

Hey @mhatipog, thanks for the PR. We're retiring the event scrubber in favor of data_collection, which allows you to specify scrubbing rules for query strings. Considering that, we'll not invest more time in improving the current default event scrubber.

For anyone reading this: If you can't migrate to data_collection, you can still define your own event scrubber that implements scrubbing fit for your usecase. Just note that event_scrubber will be removed in version 3.0 of the SDK. Alternatively, modifying the event in before_send is also an option (and one that will still be around in 3.0).

[mhatipog]

Thanks for clarifying, Ivana. I hadn't realized event_scrubber was being phased out. Makes sense to close this; I'll take a look at the data_collection path instead.