Instrument the auth path: time to first login, deliverability, drop-off, device class

[Bccorb]

seamless-idea-api/AGENTS.md makes an argument this repository is the only
place that can act on:

Every generated application is also a live Seamless Auth deployment, which is
the strategic point. Personal software is better traffic than validation apps
were: twelve family members signing in for three years exercises
deliverability, cross-device magic links, expired links and password managers
far harder than five reviewers touching an app once.

Instrument this from day one. That telemetry, not the generated apps
themselves, is what converts skeptical technical buyers to Seamless Auth.

None of it can be backfilled. Every sign in that happens before the
instrumentation exists is a reading thrown away, and the Seamless Idea fleet is
about to start producing them.

The four measurements

Measurement	Why it is the one that matters
Time to first login	The whole passwordless claim, in one number
Deliverability by mail provider	The failure mode buyers actually fear, and the one no competitor publishes
Drop off per step	Where a real person gives up, as opposed to where we assume they do
Failure rate by device class	Where passkeys and magic links genuinely differ, rather than in theory

Two audiences, one dataset

Internally this is the input to the north star for Seamless Idea, which is
whether somebody other than the owner signed in during week four. That query
needs per deployment sign in events with an owner flag, so the shape of what is
recorded here decides whether that question is answerable at all.

Externally it is a sales asset. Published operational telemetry across a fleet
of real deployments is something nobody else in this market can produce, and it
is aimed at exactly the sceptical technical buyer who does not believe managed
auth marketing. seamless-idea-api/AGENTS.md is explicit that this is what to
publish, rather than a gallery of generated applications.

Constraints

Whatever is recorded has to survive being published, which argues for
aggregates and provider names rather than addresses, and for a deliberate
decision about retention before the first row exists rather than after.

Done when

One query answers "how many logins, across how many deployments, at what
success rate", broken down by mail provider and device class, and the first
shared idea application produces rows in it.

[Bccorb]

Scoping note. Three of the numbers people will ask this dataset for are already
answerable from rows the API writes today, so they are split out to #302 as
read-side work that does not wait on this issue:

• time to registration (per new user, user_created to first completed sign-in),
  which is what this issue calls "time to first login"
• passkey adoption (share of users with a credentials row, and the interval to
  the first one)
• time to login (per returning attempt, login_success to the next completed
  sign-in)

This issue keeps everything that cannot be backfilled and needs a write-path
change before the Seamless Idea fleet starts producing sign-ins:

• mail provider on every send (nothing records the recipient domain today, and
  notification_sent is only the owner notice)
• a device class (raw user_agent is stored on auth_events, nothing
  classifies it)
• an owner flag and a deployment id on sign-in events, for the week-four query
• the retention and publishability decision
• optionally a jti on the ephemeral token, logged into both ends of an attempt,
  so time to login can attribute exactly instead of by adjacency (the ephemeral
  token has no jti today and session_id is null before a session exists)

Once the #302 queries exist, the deployment, owner, and device class dimensions
from here slot in as GROUP BYs on the same rows.