Support the new DataCollection option (successor to SendDefaultPii)

## Overview

The [DataCollection spec]() replaces the binary `SendDefaultPii` flag with a structured `DataCollection` option that gives users per-category control over automatically collected data:

* `UserInfo` (id/email/username/ip) — default `true`
* `Cookies`, `HttpHeaders` (request/response), `UrlQueryParams` — key-value collection behavior: `off` / `denyList` (default) / `allowList` over a canonical sensitive-terms denylist, values replaced with `[Filtered]`
* `HttpBodies` — which of the four directions (incoming/outgoing × request/response) to attach
* `GraphQL` (document/variables), `GenAI` (inputs/outputs), `DatabaseQueryData`, `Queues`, `StackFrameVariables`, `FrameContextLines`

Reference implementation: sentry-javascript, tracked in [getsentry/sentry-javascript#20141]() (foundation PR [getsentry/sentry-javascript#20965]()). JS shipped the entire migration in v10 **minor releases with zero behavior changes for existing users**; removal of `sendDefaultPii` is deferred to their next major.

## Strategy

Following the JS playbook:

* **Resolve once, read everywhere**: `DataCollection` is resolved to an internal fully-populated config at SDK init; all consumers read only the resolved object.
* **Bridge**: when `DataCollection` is not set, the resolved config is derived from `SendDefaultPii` (`true` → everything on; `false`/unset → restrictive + GDPR deny-terms). If both are set, `SendDefaultPii` is ignored.
* **New permissive defaults (user identity and HTTP bodies collected by default) apply only when the user explicitly sets** `DataCollection` — nobody's behavior changes until the next major.
* **User-set data is never gated** (e.g. an explicitly set `User`); `DataCollection` only gates automatic collection.
* **Integration-level options take precedence** over the global `DataCollection` layer (e.g. `MaxRequestBodySize`, `SentryAIOptions.RecordInputs`).
* Every PR is independently shippable and behavior-neutral. Phase 0 tightens default privacy with no new API and is useful standalone.

## Phases

### Phase 0 — Hardening pre-work (no new API, each independently useful)

- [ ] getsentry/sentry-dotnet#5421 sensitive-terms denylist + key-value filtering utility
- [ ] getsentry/sentry-dotnet#5422 always redact sensitive header values
- [ ] getsentry/sentry-dotnet#5423 per-cookie parsing + sensitive cookie-name filtering
- [ ] getsentry/sentry-dotnet#5424 scrub sensitive URL query parameters

### Phase 1 — Foundation (option is a documented no-op after this)

- [ ] getsentry/sentry-dotnet#5425 option types
- [ ] getsentry/sentry-dotnet#5426 resolver + SendDefaultPii bridge
- [ ] getsentry/sentry-dotnet#5427 config binding (appsettings)

### Phase 2 — Consumer migrations (behavior-neutral, one PR per area)

- [ ] getsentry/sentry-dotnet#5428 core enricher (UserInfo)
- [ ] getsentry/sentry-dotnet#5429 redact cascade + HTTP failed-request handler
- [ ] getsentry/sentry-dotnet#5430 Sentry.AspNetCore
- [ ] getsentry/sentry-dotnet#5431 Sentry.AspNet ([System.Web]())
- [ ] getsentry/sentry-dotnet#5432 GraphQL instrumentation
- [ ] getsentry/sentry-dotnet#5433 database query data
- [ ] getsentry/sentry-dotnet#5434 [Sentry.Extensions.AI]() (GenAI)
- [ ] getsentry/sentry-dotnet#5435 OpenTelemetry + logging integrations
- [ ] getsentry/sentry-dotnet#5436 native propagation (Android/Cocoa)

### Phase 3 — Deprecation (minor)

- [ ] getsentry/sentry-dotnet#5437 deprecate SendDefaultPii

### Phase 4 — Defaults flip (minor, only for explicit DataCollection users)

- [ ] getsentry/sentry-dotnet#5438 spec defaults

### Phase 5 — Next major

- [ ] getsentry/sentry-dotnet#5439 remove SendDefaultPii

## .NET-specific notes

* **Native propagation**: until sentry-java / sentry-cocoa implement the spec, the resolved config is down-converted to the native `sendDefaultPii` boolean (conservatively).
* **Config binding**: the option shape must bind from `appsettings.json` (`BindableSentryOptions` and friends) — a requirement JS didn't have.
* `[Obsolete]` **timing**: unlike JSDoc `@deprecated`, `[Obsolete]` produces compiler warnings that break `TreatWarningsAsErrors` builds. Docs/changelog deprecation lands in a minor; attribute timing to be decided (see the deprecation sub-issue).
* **Spec categories .NET can't act on yet** (`Queues` — no queue integration captures args; `StackFrameVariables` / `FrameContextLines` — native-layer only): included in the option shape from day one and forwarded to native where relevant. JS added `graphQL`/`databaseQueryData` late and had to re-gate integrations ([getsentry/sentry-javascript#22219]()) and rename `queryParams` → `urlQueryParams` ([getsentry/sentry-javascript#22217]()) — we use final spec names from the start.
* Docs work (options page, migration guide, "data collected" pages) is tracked separately in sentry-docs.

Start with the linked DataCollection spec and the sentry-javascript reference implementation, then use the listed sentry-dotnet issues 5421–5439 to identify one independently shippable phase. Done means implementing the selected phase while preserving existing-user behavior and completing its stated migration, configuration, or privacy goal.

Written by the indexing model from the issue text.