Add production OTP delivery through Relay-backed auth contact channels

[jeremi]

Context

The current plugin has a pluggable ChallengeVerifier and a static OTP verifier for local development. That is fine for demos, but production login needs a real OTP path. We do not want Novu as a required dependency. We also should not treat phone/email used for authentication as ordinary shareable OIDC claims.

Desired design

• eSignet authenticates a person by calling a Relay auth/contact profile, separate from the normal UserInfo profile.
• The auth/contact profile returns only auth-usable contact channel data, for example verified phone/email or, later, opaque channel ids and masked display values.
• The plugin owns OTP generation, expiry, retry limits, rate limiting, transaction binding, and verification.
• Delivery should be provider-based and simple:
  • static/log provider for local dev
  • SMTP/email webhook provider
  • SMS webhook provider
  • optional adapters can come later

Security requirements

• OTP is bound to transaction id, subject, relying party, client id, and channel.
• OTP is single-use and expires quickly.
• Generating a new OTP must not reset failed attempt counters.
• Responses must avoid subject enumeration. Unknown, inactive, no-channel, and delivery failure should not produce distinct user-visible messages.
• Do not log raw OTPs, raw phone numbers, raw email addresses, tokens, or full Relay responses.

Acceptance criteria

• Define the production ChallengeVerifier/delivery extension points and document how to configure them.
• Add an auth/contact Relay request path that is separate from UserInfo release.
• Add tests for OTP expiry, single-use, failed attempt limits, resend behavior, and subject-enumeration collapse.
• Add docs showing static/log local mode and one generic webhook delivery mode.

Notes

This ticket intentionally keeps Novu out. If a deployment wants a notification service later, it can implement the delivery provider interface.