Connect sign-up to Sendico Facts intake (#46)

docs/auth-notifications.md

@@ -61,7 +61,7 @@ envelope. Credentials, codes and activation tokens are sent in POST bodies.
 
 | Route | Request | Successful result |
 | --- | --- | --- |
-| POST `/signup` | `name`, `email`, `password`, `locale`, `idempotencyKey` | 202 with `userId`, after activation email queue acceptance |
+| POST `/signup` | `name`, `email`, `password`, `locale`, `idempotencyKey` | 202 with `userId`, after configured Facts intake and activation email queue acceptance |
 | POST `/verification/send` | `email`, `idempotencyKey` | 202; generic acceptance also applies to absent/already-active accounts |
 | POST `/verification/confirm` | `token` | 202 with `verified: true` after activation commits |
 | POST `/login` | `login: {login, password}`, `clientId`, `deviceId` | 202 with `userId`, `pendingToken: {token, expiration}`, `challengeId`, `channel`, masked `target`, `expiresAt`, `resendAt` |
@@ -101,6 +101,14 @@ retries can create replacement messages; they are not distributed exactly-once
 operations. Tokens are stored before the RPC, so a process crash between those
 steps requires user recovery; there is no product-side delivery outbox.
 
+When `api.sendico` is enabled, sign-up and activation resend first require a
+durable Facts intake receipt. Activation checks that receipt in its transaction.
+Initial account/token creation uses the same server-secret-derived activation
+key as a same-key retry, so an intake outage does not force an extra cooldown for
+an unsent initial token. Existing pending customers created before this change
+retain the prior cooldown behavior. See [Facts integration](signup-facts.md) for
+uncertain registration recovery and the `signup_attention_required` error.
+
 Code verification, one-use proof consumption and session creation now commit in
 one transaction. A session-write failure leaves the code retryable; a lost HTTP
 response after commit requires restarting password login. The adapter