docs(be,fe): design doc and implementation checklist for verified emails as a first-class II primitive

[MRmarioruci]

Internet Identity has a single recovery-email slot per anchor, verified through an inbound DKIM/DMARC/DNSSEC ownership-proof flow. Dapps can request email / name / verified_email attributes but only from linked OpenID/SSO sources — the recovery email is invisible to that surface. Users can't add multiple verified emails for any other purpose, and there's no way to share an email with a dapp that doesn't go through a third-party identity provider.

This PR adds two design artifacts to start the conversation; no code changes.

Changes

Two new files under docs/design/:

• verified-email-attributes.md — design doc. Proposes adding verified emails as a new, independent first-class anchor primitive that lives alongside the existing recovery-email slot. The recovery flow stays untouched; verified emails are a parallel new feature that shares the verification primitive (inbound DKIM challenge) but uses separate storage, separate candid methods, a separate wizard component, a separate II-Verify- subject prefix, and a separate PendingKind::VerifyEmail variant. Four phases, each shipping as a single release:
  • Phase 1: verified-emails primitive — new StorableVerifiedEmail type, new verified_emails field added additively (no migration), new verified_email_* candid surface, new wizard + narrow settings panel + /authorize empty-state inline flow.
  • Phase 1.5: pure-FE "Reach" page that widens the narrow panel into a unified dashboard surfacing OIDC/SSO emails alongside verified_emails entries, with a separate "Unverified emails" section and a Verify-from-unverified flow that promotes IdP-issued emails through the DKIM challenge.
  • Phase 2: verified emails as ICRC-3 attribute sources under a new verified:<H(address)>:email scope. Recovery email is intentionally not exposed.
  • Phase 3: smart-routing + last-used default in the consent dialog; no per-dapp pin, no global "don't share" toggle (sharing is per-request, always).
• verified-email-implementation.md — operational checklist. File-path-level steps for implementers, with locked decisions stated up front (cap=5, additive storage, parallel concepts, no migration, dual-prefix parser, verifiedEmail/ wizard directory, "Reach" page name with per-IdP source icons) and a suggested PR breakdown for the eventual feature work.

Includes a "Copy and tone" subsection that commits to framing the share as a net benefit rather than as friction, with principles for the new surfaces (empty-state prompt, settings panel, wizard success) and explicit non-changes for the existing consent dialog.

Both files cross-link to each other. The design doc explains why; the checklist is what to do.