chore: INFRA-295 correct Sentry release-health session option + crash attribution

[MP2EZ]

Closes INFRA-295

Re-scoped: a planning panel falsified the story's premise. The item assumed release-health session tracking was deliberately disabled and needed enabling. It was not disabled.

1. The option key was dead

ExternalErrorReporter passed autoSessionTracking: false, but @sentry/react-native reads enableAutoSessionTracking. The key we set does not exist in the SDK, is forwarded verbatim to the native layer, and is ignored there — and both native SDKs default session tracking ON.

enableAutoSessionTracking  → 4 files in @sentry/react-native/dist/js
autoSessionTracking (bare) → 0 files

So the "privacy-first, error-only" posture the code comment and runbook §1 both credited was never in effect: sessions have most likely been transmitting from every non-__DEV__ build, including the 2026-06-15 TestFlight build. TypeScript can't catch this — the RN options type carries an index signature.

2. Crash attribution was broken (independent defect)

applyAllowlist rebuilt exception.values as {type, value, stacktrace}, dropping mechanism; level was absent from ALLOWED_ERROR_FIELDS. The SDK's isHardCrash() requires mechanism.handled === false && mechanism.type === 'onerror', and beforeSend runs before envelope creation — so no JS fatal error ever marked its session crashed.

A crash-free-session-rate alert built on that would have counted native crashes only and read systematically optimistic, under-firing exactly when it mattered. Now preserved as explicitly type-guarded named scalars — never a spread, so the SDK's open mechanism.data bag can't ride along — plus an enum guard on level so it can't become a free-text channel.

3. Contract test

app/__tests__/privacy/releaseHealthSession.contract.test.ts (15 tests, runs in precommit via test:privacy). Red phase confirmed first: isHardCrash(scrubbed) returned false against the old code. The test imports the SDK's real isHardCrash, so an upstream change to the crash-attribution rule fails the build rather than silently zeroing the metric.

4. Docs reconciled to reality

• privacy-policy.md §5.1 — previously promised Sentry receives "no device identifier", contradicted by the session did (a per-install UUID; no Sentry.setUser exists in app/src, so the iOS layer injects user.id = installationID). Replaced with an accurate disclosure.
• dpia-sensitive-wellness-data.md v1.7 — retrospective control-status correction. Assessed not a breach: no wellness content exposed, and the value is a device-scoped install identifier, not PHR identifiable health information under 16 CFR Part 318. Not a §1 material-change trigger — Sentry was already an authorized sub-processor.
• post-launch-monitoring-runbook.md §1 — its "no data source today" warning was wrong, and the interim Number-of-Errors alert it said would be superseded was never created (verified live: being-prod has one rule, the default onboarding issue alert, and zero metric alerts).

Session envelopes bypass beforeSend/normalizeDepth entirely (envelope session items, not events), so the controls the original AC named never applied to them; the review was done against the fixed session schema instead.

Compliance agent verdict: privacy-neutral — mechanism.type/handled/synthetic and level are all closed-vocabulary SDK-controlled values, and the app never constructs a mechanism anywhere.

Not claimed by this PR

Creating the crash-free-session-rate metric alert and verifying Releases → Health require the Sentry dashboard and a new TestFlight build (the Sentry MCP is read-only for alert rules). Recorded as an operator checklist on the Notion item.

Verification

npm run precommit exit 0 — safety 108, clinical 106, unit 568, privacy 51 tests passed.

🤖 Generated with Claude Code