EmailProvider accepts dotless email addresses (e.g. scott@willeke) and attempts delivery

## Problem

During fernfiles' rollout a user typo'd `scott@willeke` (no TLD) into the sign-in form. HTML `type=email` accepts dotless domains, and `EmailProvider.initiate` performed no address validation of its own — it accepted the identifier, created the user/identity via the store, and would have attempted SMTP delivery to an unroutable address. The app only caught it downstream (an admin-approval notification for a garbage identity).

## Ask

1. **Server-side**: `EmailProvider` (or a shared identifier-validation hook in `@activescott/auth`) should reject clearly-invalid email addresses at initiate, before any store writes or transport sends. A pragmatic default: require `local@domain.tld` (dot in the domain), configurable/escape-hatchable for intranet cases (`user@localhost`). Returning the standard validation-error redirect (the same path as a missing address) gives every consumer app the fix for free.
2. **Docs/example**: the react-router example's sign-in form could add `pattern=".+@.+\..+"` + `title` alongside `type=email` so the browser catches it first (fernfiles now does this — activescott/fernfiles#6).

## Why the library and not the app

Every consumer must otherwise re-discover this: identity providers own identifier semantics (the SMS provider presumably validates E.164 — email deserves the same). The store-write side effect makes it worse than a failed send: apps that key approval workflows on identities (fernfiles' waitlist) accumulate junk identities from typos.

Context: found while debugging activescott/fernfiles sign-in (fernfiles#6).