People sign in before they ask for a key: the common way to meet this
deployment is to try the front door, fail the allowlist, and land on
/access-denied. That page pointed at /request, where the first thing asked
for was the handle OAuth had just proven.

It now carries the form itself. No handle field — the identity came out of
the sign-in — and the name is prefilled from the Bluesky profile, so asking
is one button. Three things follow from the requester being identified:

- The request is stored with a verified DID. On a pending request that can
  only have come from OAuth, which the admin card now says ("Signed in"),
  and approval looks the profile up by DID rather than by handle — so a
  handle that has moved, or whose domain is down, no longer blocks it.
- No status link to keep: signing in again is the status check, so a second
  visit shows the pending state and the POST returns to /access-denied.
- One open request per person, since a duplicate is now recognisable.

Same POST /request endpoint, so the honeypot, rate limit and both field
gates stay in one place; it branches only on where errors render and where
the handle comes from. The anonymous /request page is unchanged.

The e2e fixture needed a visitor who is signed in and not a member, which
the Members table cannot produce because it *is* the allowlist — hence
/dev/login/{did}?handle=, still Development-only and still the one backdoor.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -713,1 +758,4 @@
+        !string.IsNullOrEmpty(signedInDid) ? $"/access-denied?error={error}"
+        : isInvite ? $"/request?kind=invite&error={error}"
+        : $"/request?error={error}";