refactor: consolidate Sentry noise filters into a declarative registry

[sw-factory-automations]

Description

The Sentry event filtering system (src/lib/sentry/event-filters.ts) has grown reactively — each new noise pattern discovered via the Incident Responder automation results in a new bug issue, a new filter function, and a new set of tests. In the last 2 weeks, 11 Sentry-related bugs were filed and fixed (#931, #933, #937, #944, #998, #1004, #1013, #1083, #1084, #1114, #1144), all following this pattern.

The current approach works but creates ongoing maintenance churn. A declarative noise registry would let new patterns be added as data (a config entry) rather than code (a new function + tests), reducing the per-pattern cost from a full PR to a single line addition.

Acceptance Criteria

• Create a NoisePattern type with fields: name (string identifier), match (predicate function or declarative matcher config), reason (why this is noise, for documentation)
• Create a NOISE_REGISTRY: NoisePattern[] array in src/lib/sentry/noise-registry.ts that consolidates all existing filter patterns from event-filters.ts
• Refactor beforeSend in Sentry config to iterate the registry instead of calling individual filter functions
• Each existing filter (isNextjsInternalNoise, isReactLexicalDomConflict, isTransientSupabaseNetworkEvent, isSupabaseAuthLockContention) is migrated to a registry entry
• The existing 171 Sentry unit tests continue to pass (no behavior change)
• Add a convention to .agents/conventions.md documenting how to add new noise patterns via the registry
• pnpm lint && pnpm typecheck && pnpm test pass

Dependencies

None

Technical Notes

• Current filters: src/lib/sentry/event-filters.ts (175 lines, 4 exported functions)
• E2E detection: src/lib/sentry/e2e-detection.ts (98 lines) — separate concern, leave as-is
• Sentry config: src/instrumentation-client.ts and src/instrumentation.ts call the filters in beforeSend
• Unit tests: src/lib/sentry.unit.test.ts (171 tests) — these should not need changes if the refactor preserves the same filtering behavior
• The registry pattern is already used in the codebase for property types (Record<PropertyType, { Renderer, Editor }>) — follow the same approach
• Keep the individual filter functions as private helpers within the registry module for complex matching logic (e.g., isReactLexicalDomConflict checks frame origins). The registry entry just references them.
• This is a pure refactor — no new filtering behavior, no changes to what gets dropped or kept

Approval Required

This is a HIGH risk change:

• Modifies the Sentry beforeSend pipeline that controls which errors reach the monitoring dashboard
• A regression could silently drop real errors or flood Sentry with noise
• The 171 existing unit tests provide a safety net, but the refactor touches the integration point between filters and Sentry config
• Recommend reviewing the PR diff carefully to ensure no filter is accidentally dropped or weakened

Comment "approved" to release this to the automation queue.