Sentry: narrower scrub rule for bare rootkey-shaped tokens (base64-22)

[gmaclennan]

Part of #74. Re-scoped after PR #111 — the scrubbers themselves landed there; this issue now covers the one deliberately-disabled rule.

Landed in #111: the shared regex list mirrored between src/sentry-scrub.ts (RN beforeSend, ahead of the host's chain) and backend/before-send.js (Node event processor), walking message / exception text / extra / contexts / breadcrumbs / span data + structured logs; rootKey-marker and coordinate-marker redaction (lat/lng/lon/latitude/longitude, key-value and JSON-quoted forms); HTTP breadcrumb URLs reduced to host-only; shared test cases in test-support/scrubber-cases.js.

Remaining: the broad 22-char base64 rule (to catch a bare rootkey with no rootKey= marker) is intentionally disabled — it also matched Sentry's own 32-hex trace ids, PascalCase exception type names, and error_class metric tags, redacting data we need. Until a narrower rule ships, a bare unmarked rootkey embedded in an error message passes through unredacted.

Done when

• A narrower detection for bare rootkey-shaped tokens is agreed (options: exact-length 22-char URL-safe base64 with entropy check; context exclusions for trace-id/type-name shapes; or an allowlist of known-safe field paths) and enabled in both scrubber copies
• The disabled-rule notes in src/sentry-scrub.ts, backend/before-send.js, and docs/sentry-integration.md §8 are updated
• Shared cases in test-support/scrubber-cases.js: bare rootkey redacts; trace ids, exception type names, and error_class values survive

[gmaclennan]

Re-scoped: the scrubber implementation landed with PR #111; this issue now tracks only the narrower bare-token (base64-22) rule that #111 deliberately disabled. Original body is in the edit history.