LiveView for resending email confirmation instructions.

Allows users to request a new confirmation email if they didn't receive the original or if the link expired. Only sends if the account exists and is not already confirmed.

This page is also where the authentication gates park logged-in users whose email is not yet confirmed (when require_email_confirmation is on), so it moves them along as soon as confirmation happens:

• On mount, an already-confirmed user is redirected onward immediately — covers a confirmation done elsewhere (or directly in the DB) followed by a refresh, since the user is reloaded from the DB on every mount.
• While parked, the LiveView listens on this user's own confirmation topic for {:user_confirmed, user} (broadcast by both the email-link flow and the admin confirm action) and redirects onward live, no refresh needed — e.g. when the user clicks the emailed link in another tab. It is a per-user topic, not the site-wide admin users feed, so a parked non-admin never receives other users' structs.
• A parked user can also fix a typo'd address instead of only resending to it: "Wrong email?" reveals a bare new-address form — no password, unlike Profile Settings' confirmed-user change-email flow, because there is no live/confirmed account yet for a hijacked session to protect (see Auth.apply_unconfirmed_user_email/2). The emailed link points at PhoenixKitWeb.Users.ConfirmEmailChange (/users/confirm/change-email/:token), NOT the normal /profile/settings/confirm-email/:token landing page — that one sits behind the authenticated-AND-confirmed live_session, which an unconfirmed user fixing their email could never pass. Confirming the new address there changes the account's email AND confirms it in one step (Auth.update_user_email/2 runs confirm_changeset either way), so there is no separate "now confirm again" round trip.

"Onward" is ?return_to= (stashed by the gate that parked them), then the session's user_return_to, then the after_login_path setting.