fix: address the feature review — accurate copy, reachable controls, real coverage

Round 1 on the feature diff found 15; the substantive ones:

- The delete control VANISHED on any invite whose address had registered, which
  is the ordinary sign-up shape (register writes the User and the pending invite
  together). The guard stays broad — that row is the account's approval gate, and
  orphaning it strands someone who can then neither sign in nor be approved — but
  the control is now a disabled button carrying the reason, on both lists, so an
  admin never sees a row silently missing a button its neighbours have.
- Deleting an entry is not always a revoke: is_allowed falls back to the env
  ALLOWED_EMAILS / ADMIN_EMAILS lists once no row exists, and an ADMIN_EMAILS
  address is force-promoted on its next Google sign-in. The route now reports
  still_allowed_by_env and the UI says so instead of claiming access was removed.
- "Deny keeps the row so they can't immediately re-ask" was simply false —
  upsert_pending_invite reopens a denied row. Corrected everywhere it was stated.
- The Configuration warning reads me.email_configured, which save() did not
  invalidate, so it kept warning about fields the admin had just filled in.
- The read-only variant was an aria-hidden span explained only by a Tooltip that
  the hints toggle can switch off; now a disabled button with title + aria-label.
- The delete error path threw away the 409's reason (the stale-list case) and
  left the stale row on screen.
- The throttle window was spent even when no notice was written, silencing the
  next hour on the path whose job is to stop silent drops.
- email_enabled() opened a second session and decrypted the SMTP password on
  every /api/me poll; it now takes the caller's session.
- welcomeMode.dom.test.ts never rendered the card, so reverting the history
  wiring to useState left it green. A render test now drives the real links and
  fails on that revert (verified).

Plus /api/me flag tests, the registration-shaped pending case, the env-allowlist
case, and a release note that matches what the code does.

backend/tests/test_admin_invites.py

@@ -27,7 +27,7 @@ def test_admin_deletes_a_whitelist_entry_that_never_became_an_account(db, make_u
 
     r = client.delete(f"/api/admin/invites/{listed['id']}")
 
-    assert r.status_code == 200 and r.json() == {"deleted": listed["id"]}
+    assert r.status_code == 200 and r.json()["deleted"] == listed["id"]
     db.expire_all()
     assert (
         db.execute(select(Invite).where(Invite.email == "mistake@example.com")).scalar_one_or_none()
@@ -56,6 +56,50 @@ def test_deleting_an_entry_that_has_an_account_is_refused(db, make_user, as_user
     )
 
 
+def test_a_pending_request_from_a_registration_is_not_deletable(db, make_user, as_user):
+    # The shape the ordinary sign-up produces: _register_account writes the User (inactive) AND the
+    # pending Invite together. The invite is that account's approval gate, so deleting it would
+    # strand the person — they could neither sign in nor be approved, and re-registering is a silent
+    # no-op. Managed from Users & roles instead, which is what the UI and the 409 both say.
+    admin = make_user(email="admin@example.com", role="admin")
+    make_user(email="signup@example.com", is_active=False, email_verified=False)
+    db.add(Invite(email="signup@example.com", status="pending"))
+    db.commit()
+    client = as_user(admin)
+    listed = _invites(client)["signup@example.com"]
+    assert listed["has_account"] is True  # the UI shows a disabled control, not a missing one
+
+    r = client.delete(f"/api/admin/invites/{listed['id']}")
+
+    assert r.status_code == 409
+    db.expire_all()
+    assert (
+        db.execute(select(Invite).where(Invite.email == "signup@example.com")).scalar_one_or_none()
+        is not None
+    )
+
+
+def test_deleting_an_env_allow_listed_address_reports_that_it_kept_access(
+    db, make_user, as_user, monkeypatch
+):
+    # Removing the row is NOT always a revoke: is_allowed falls back to the env bootstrap lists once
+    # no invite exists. The admin has to be told, or they think they removed access and did not.
+    from app.config import settings
+
+    monkeypatch.setattr(
+        type(settings), "allowed_email_set", property(lambda self: {"ops@example.com"})
+    )
+    admin = make_user(email="admin@example.com", role="admin")
+    db.add(Invite(email="ops@example.com", status="approved", decided_by=admin.email))
+    db.commit()
+    client = as_user(admin)
+
+    r = client.delete(f"/api/admin/invites/{_invites(client)['ops@example.com']['id']}")
+
+    assert r.status_code == 200
+    assert r.json()["still_allowed_by_env"] is True
+
+
 def test_deleting_a_pending_request_forgets_it(db, make_user, as_user):
     # A pending row is deletable too — "not now, and don't keep the record" is a different decision
     # from Deny, which keeps the row precisely so the person cannot immediately re-ask.
@@ -67,6 +111,7 @@ def test_deleting_a_pending_request_forgets_it(db, make_user, as_user):
     r = client.delete(f"/api/admin/invites/{_invites(client)['asker@example.com']['id']}")
 
     assert r.status_code == 200
+    assert r.json()["still_allowed_by_env"] is False  # nothing in the env allow-lists
     assert "asker@example.com" not in _invites(client)