feat: notification service

integration/README.md

@@ -14,6 +14,8 @@ integration/
 ├── gatewayauthsessionmail/
 │   ├── gateway_authsession_mail_test.go
 │   └── harness_test.go
+├── gatewayauthsessionusermail/
+│   └── gateway_authsession_user_mail_test.go
 ├── authsessionuser/
 │   ├── authsession_user_test.go
 │   └── harness_test.go
@@ -26,6 +28,12 @@ integration/
 ├── gatewayuser/
 │   ├── gateway_user_test.go
 │   └── harness_test.go
+├── notificationgateway/
+│   └── notification_gateway_test.go
+├── notificationmail/
+│   └── notification_mail_test.go
+├── notificationuser/
+│   └── notification_user_test.go
 ├── go.mod
 ├── go.sum
 └── internal/
@@ -60,12 +68,27 @@ integration/
 - `gatewayauthsessionmail` verifies the public auth flow across real `Edge Gateway`, real `Auth / Session Service`, and real `Mail Service`.
 - `gatewayuser` verifies the direct authenticated self-service boundary between real `Edge Gateway` and real `User Service`.
 - `gatewayauthsessionuser` verifies the full public-auth plus authenticated-account chain across real `Edge Gateway`, real `Auth / Session Service`, and real `User Service`.
+- `notificationgateway` verifies that real `Notification Service` push
+  publication is consumed and fanned out by real `Edge Gateway` for all
+  user-facing push types.
+- `notificationmail` verifies that real `Notification Service` template-mode
+  mail publication is consumed by real `Mail Service` for all notification
+  email types.
+- `notificationuser` verifies that real `Notification Service` enriches
+  recipients through real `User Service` and preserves Redis stream progress
+  semantics for missing or temporarily unavailable users.
+- `gatewayauthsessionusermail` verifies the full public registration chain
+  across real `Edge Gateway`, real `Auth / Session Service`, real
+  `User Service`, and real `Mail Service`, including the regression that
+  auth-code mail bypasses `notification:intents`.
 
 The current fast suites still use one isolated `miniredis` instance plus either
 real downstream processes or external stateful HTTP stubs where appropriate.
-`authsessionmail` and `gatewayauthsessionmail` are the deliberate exceptions:
-they use one real Redis container through `testcontainers-go`, because those
-boundaries must exercise the real Redis-backed `Mail Service` runtime.
+`authsessionmail`, `gatewayauthsessionmail`, `notificationgateway`,
+`notificationmail`, `notificationuser`, and `gatewayauthsessionusermail` are
+the deliberate exceptions: they use one real Redis container through
+`testcontainers-go`, because those boundaries must exercise real Redis stream,
+persistence, or scheduling behavior.
 `authsessionmail` additionally contains one targeted SMTP-capture scenario for
 the real `smtp` provider path, while `gatewayauthsessionmail` keeps `Mail
 Service` in `stub` mode and extracts the confirmation code through the trusted
@@ -83,6 +106,10 @@ go test ./authsessionmail/...
 go test ./gatewayauthsessionmail/...
 go test ./gatewayuser/...
 go test ./gatewayauthsessionuser/...
+go test ./notificationgateway/...
+go test ./notificationmail/...
+go test ./notificationuser/...
+go test ./gatewayauthsessionusermail/...
 ```
 
 Useful regression commands after boundary changes:
@@ -94,6 +121,10 @@ go test ./authsessionmail/...
 go test ./gatewayauthsessionmail/...
 go test ./gatewayuser/...
 go test ./gatewayauthsessionuser/...
+go test ./notificationgateway/...
+go test ./notificationmail/...
+go test ./notificationuser/...
+go test ./gatewayauthsessionusermail/...
 cd ../gateway && go test ./...
 cd ../authsession && go test ./... -run GatewayCompatibility
 cd ../user && go test ./...