PREWAVE-BE-018 — Converge Duplicate Notification Module Implementations #613

Problem context

Draft PR #608 proves deterministic installation under the pinned Node runtime, but hosted Gate B still fails at source compilation. This issue isolates one concrete failure family from the 77-error baseline.

Technical scope

• Audit notifications.module.new.ts against the active notification module.
• Preserve reviewed functionality, remove obsolete duplicate wiring, and publish one module entrypoint.
• Document migrations for any retained model changes.
• Reconcile the active legacy processor with the newer channel/orchestrator stack. The current notifications.module.ts registers src/notifications/services/notification.processor.ts, whose EMAIL path uses the hard-coded destination user@example.com and whose PUSH path reports that push is not implemented. The older NotificationService.processDelivery() also needs to be proven not to mark a delivery as successful without a provider-confirmed send.
• Either retire these legacy paths from production or migrate their required behavior into the single canonical channel/orchestrator path. Do not leave an alternate production worker able to send to a placeholder address or record synthetic delivery success.

Security and architecture constraints

• Contracts and finalized canonical events remain authoritative for protocol state.
• Do not conceal errors with broad casts, disabled strictness, skipped tests, or duplicate compatibility models.
• Treat wallet, request, notification, support, and chain-derived inputs as untrusted.
• Preserve fail-closed behavior for missing configuration and interface mismatches.
• No hard-coded recipient addresses, mock delivery IDs, or synthetic provider success in production.

Required tests

• Nest module bootstrap test.
• Provider uniqueness and queue-consumer uniqueness tests.
• Regression tests for each retained channel.
• Test proving email is routed only to the verified recipient resolved from the notification/user record.
• Test proving an unavailable or unimplemented channel cannot be recorded as delivered.
• Test proving no legacy processor or duplicate queue remains reachable from the production module.

Acceptance criteria

• Exactly one production notification module is registered.
• No provider or worker is instantiated twice.
• Obsolete .new implementation paths are removed or explicitly test-only.
• Startup and shutdown complete without leaked handles.
• No production notification path uses user@example.com or another placeholder destination.
• A delivery is marked delivered only after a provider-confirmed send or an explicitly defined in-app delivery operation.
• Retained SMTP, push, webhook, WebSocket, and in-app channels have explicit truthful outcomes.
• Exact-head CI and independent review pass.

Dependencies

• STAB-BE-005 — Restore the Post-Wave-9 Install and CI Baseline #584
• fix(ci): align API dependencies and Node runtime #608

Non-goals

• Bundling unrelated compile repairs.
• Weakening TypeScript, lint, security, or container gates.
• Mainnet deployment.
• Applying Stellar Wave before maintainer activation.

Complexity and points

• Medium — 150 points

Candidate only; activation remains maintainer-controlled.