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).