Log redacted email provider errors and diagnose sender configuration (#57)

docs/signup-facts.md

@@ -38,12 +38,12 @@ and service cancellation still ends it.
 
 The rebuilt worker processed the queued activation message. The live Resend
 provider rejected it with `provider_authentication_failed` (HTTP 401 or 403),
-leaving delivery in `failed` after one attempt. The configured API key/sender
-authorization must be corrected before sending another activation email. Rotate
-the credential securely with `make email`, wait for Vault Agent to refresh it,
-restart notifications so it reloads its environment, then use activation resend
-with a new idempotency key. Do not replay the failed notification as a success or
-mark the customer active on their behalf.
+leaving delivery in `failed` after one attempt. Later diagnostics below identify
+the unverified sender domain as the actual blocker. Correct domain authorization
+before activation resend with a new idempotency key. Credential rotation is not
+required by that error; if a separate rotation is needed, use `make email` and
+allow Vault Agent to refresh/restart the notification process. Do not replay the
+failed notification as a success or mark the customer active on their behalf.
 
 Validation passed: `GOFLAGS=-p=2 make test` (all backend race tests and canonical
 frontend suites), `make lint-backend`, focused provider/identity race tests and
@@ -59,6 +59,39 @@ is blocked by provider authorization as described above. No security scans were
 requested or run. Unrelated notifications runtime settings are excluded from
 the task commits.
 
+### Provider diagnostics follow-up
+
+The same task/PR adds transient provider diagnostics to the worker's existing
+structured outcome log: `provider_status`, `provider_error` and
+`provider_message`. The adapter extracts bounded Resend/SendGrid error fields and
+redacts credentials, request values, addresses, URLs and token/code fragments.
+Transport errors have a sanitized cause; invalid or oversized responses have a
+safe fallback. Diagnostics remain outside stored notification models and public
+gRPC responses. The outcome is logged even when its result write fails. See
+the [notification logging contract](../backend/notifications/README.md).
+
+Runtime inspection confirmed `email.driver: resend`, an API key in Vault, and
+sender `noreply@sxchnge.com`. A live diagnostic notification used Resend's
+documented `delivered+sxchnge-config@resend.dev` test mailbox, without retrying
+the customer's email. The rebuilt worker logged HTTP 403,
+`provider_error: validation_error`, and the sanitized message:
+`The sxchnge.com domain is not verified. Please, add and verify your domain on [redacted-url]`.
+The precise blocker is sender-domain verification, not missing local Resend
+configuration. A sending-only key is appropriate for sending; its inability to
+read Resend's logs API does not explain the original send failure. Verify the
+configured domain in Resend (and its required DNS records), or explicitly choose
+an already verified sender domain. No sender/domain/DNS setting was changed by
+this follow-up; the customer's account remains pending email confirmation.
+
+Follow-up validation passed: `GOFLAGS=-p=2 make test`, `make lint-backend`, and
+`go -C backend/notifications test -race ./email ./service -count=1`. Coverage
+includes Resend/SendGrid messages, malformed/trailing/oversized response bodies,
+credential/content/code redaction, Unicode-safe truncation, sanitized transport
+errors, and exactly one provider outcome log even when persistence fails. The
+notifications image was rebuilt from fresh stable digest pins and deployed
+healthy; the live test verified both the diagnostic log and the unchanged generic
+gRPC failure response. No security scan or real customer email retry was run.
+
 ## Behavior and boundaries
 
 With `api.sendico` configured, the product BFF creates the local pending customer