feat(auth): one mail, one click — the approval mail carries the confirmation link (E9.5 S6)

The funnel's common ordering made a person open TWO messages: one saying their access was approved,
another asking them to confirm their address. The approval mail now branches on what they actually
still have to do — carry the confirmation link, point at sign-in, or say a confirmation mail follows
once they register — so the usual case is one mail and one click. A mail that guesses wrong is worse
than a plain one: telling someone to sign in while their address is unconfirmed contradicts the
screen that will refuse them.

That embedded link lives 7 days rather than the usual 24 hours. Nobody sits waiting for an approval —
it can easily be read on Monday after a weekend, and an expired link spends the one-mail promise and
puts them back on two. The risk is small: the token only ever confirms an address; it signs nobody in
and sets no password.

The most likely root cause of the 2026-09-03 report that a confirmation mail "never arrived" is here
too, and it was never a delivery failure: re-registering an address that already had an unconfirmed
account returned in SILENCE — same cheerful "check your inbox", no mail sent at all. It now re-sends
the link. Nothing new leaks: the response and its timing are unchanged, and the public verify/resend
already does exactly this for the same input.

Whitelisting stays silent, and that is a decision, not an omission. The operator opens a door as a
possibility — usually already agreed with the person — and a row can sit approved for weeks with
nobody registering; a mail fired automatically there would be nudging someone who never asked.
Telling them is its own act on its own button, `invited_at` records it so a second click is a
decision rather than an accident, and the button only appears where nobody is behind the address yet:
"the door is open, come in" is meaningless to someone already inside.

Two things UAT caught that no test would have. Every fresh registration appeared in BOTH admin lists
at once, because the stuck-sign-ups filter keyed on "unconfirmed" — the rule is now "the address may
sign in, and this account still can't", which leaves an undecided request with the queue that owns
it. And the invitation button was offered on every approved row, half of which are existing users.

Also: the confirmation mail finally says what its link's rules are (once, 24 hours) — the reset mail
always has, while this one left the reader to discover both by meeting a dead link. The card's
"didn't get the email?" moves up under the form, and the three waiting messages name the spam folder,
which is where a first message to a fresh recipient sometimes lands.

Registration now records the language the sign-up page was in. Nothing reads it yet — the bilingual
templates are S7 — but it is the only moment that choice exists anywhere the server can see, and a
preference nobody recorded cannot be backfilled later.

UAT on localdev: re-registering re-sent the link (one token became two, one account); approval issued
a 7-day token and moved the account into the stuck list with only a re-send; whitelisting mailed
nobody; the invitation recorded itself and the row then warned that sending again would write twice.
Test data removed.

backend/app/email.py

@@ -184,19 +184,74 @@ def _send(to: list[str], subject: str, body: str, reply_to: str | None = None) -
         return False
 
 
-def send_access_approved(email: str) -> bool:
+def _next_step(verify_link: str | None, has_account: bool, hours: int) -> str:
+    """What this person actually has to do next, in the one paragraph that carries the whole flow.
+
+    Three states, because a mail that guesses wrong sends someone looking for a link that isn't
+    coming — or worse, tells them to sign in when their address is still unconfirmed and sign-in will
+    refuse them (E9.5 S4 named that state on screen; the mail must not contradict it).
+
+    The link branch is the point of the C option: in the common ordering — approve first, the person
+    signs up later, or signs up and waits — they would otherwise have to find and open TWO separate
+    messages. One mail, one click.
+    """
+    if verify_link:
+        return (
+            "You already started an account, so there is just one step left. Confirm your email "
+            "address and you're in:\n\n"
+            f"{verify_link}\n\n"
+            f"The link works once and expires in {hours} hours. If it does, you can ask for a fresh "
+            "one from the sign-in page."
+        )
+    if has_account:
+        return f"Your account is ready — just sign in:\n\n{settings.app_base}"
+    return (
+        "Create your account whenever you feel like it:\n\n"
+        f"{settings.app_base}\n\n"
+        "We'll send you a confirmation link to finish, and then you're in."
+    )
+
+
+def send_access_approved(
+    email: str, verify_link: str | None = None, has_account: bool = False, hours: int = 24
+) -> bool:
+    """Answer someone who ASKED for access. Sent automatically on approval, because a person who
+    made a request is owed a reply — unlike the admin-initiated invitation below."""
     admin = _admin_contact()
     body = (
         "Hi,\n\n"
         "Your request to use Siftlode has been approved — welcome aboard.\n\n"
-        "Open Siftlode and sign in, and your YouTube subscriptions feed will be ready:\n\n"
-        f"{settings.app_base}\n\n"
+        f"{_next_step(verify_link, has_account, hours)}\n\n"
         "If you weren't expecting this, you can ignore the message.\n\n"
         "— Siftlode" + (f"\n\nQuestions? Just reply to this email ({admin})." if admin else "")
     )
     return _send([email], "You're in — your Siftlode access is approved", body, reply_to=admin)
 
 
+def send_access_invitation(
+    email: str, verify_link: str | None = None, has_account: bool = False, hours: int = 24
+) -> bool:
+    """Invite someone the admin let in WITHOUT them asking — sent only when the admin presses send.
+
+    Whitelisting an address is opening a door, not knocking on one: the operator has usually already
+    agreed it with the person, and an address can sit approved for weeks without anyone registering.
+    So adding to the whitelist stays silent and this is a separate, deliberate act. That is also why
+    the closing line offers no deadline — nudging is the one thing this mail must not do.
+    """
+    admin = _admin_contact()
+    body = (
+        "Hi,\n\n"
+        "Someone has opened up Siftlode for you — a quiet, self-hosted reader for your YouTube "
+        "subscriptions. Every upload from the channels you follow lands in one feed you can "
+        "actually filter and sort, with no algorithm deciding what you see, and no Shorts or "
+        "livestreams unless you want them.\n\n"
+        f"{_next_step(verify_link, has_account, hours)}\n\n"
+        "No rush — the door stays open.\n\n"
+        "— Siftlode" + (f"\n\nQuestions? Just reply to this email ({admin})." if admin else "")
+    )
+    return _send([email], "You're invited to Siftlode", body, reply_to=admin)
+
+
 def send_access_denied(email: str) -> bool:
     admin = _admin_contact()
     body = (
@@ -277,11 +332,15 @@ def send_admin_new_request(admins: list[str], requester: str) -> bool:
     return _send(admins, f"Siftlode access request from {requester}", body, reply_to=requester)
 
 
-def send_verify_email(to: str, link: str) -> bool:
+def send_verify_email(to: str, link: str, hours: int = 24) -> bool:
     body = (
         "Hi,\n\n"
         "Confirm your email to finish creating your Siftlode account:\n\n"
         f"{link}\n\n"
+        # Say what the link's rules are. The reset mail always has; this one left the reader to
+        # discover both by meeting a dead link, which is precisely the silence this epic removes.
+        f"The link works once and expires in {hours} hours. If it does, you can ask for a fresh one "
+        "from the sign-in page.\n\n"
         "If you didn't sign up, you can ignore this message.\n\n"
         "— Siftlode"
     )