Let a passkey satisfy the passkey-removal step-up

The gate landed with a softer mode for accounts holding no second factor,
on the premise that they could not clear it. That premise was wrong. A
passkey is a possession factor here and the codebase already says so in
three places: a primary passkey login stamps Session.mfaVerifiedAt,
passkey sits in FRESH_FACTOR_METHODS so a passkey-proved elevation reaches
the fresh-factor routes, and the enrolment policy counts a primary passkey
as satisfying it outright. The only thing refusing such an account was the
reachability pre-check inside requireFreshMfa, which counts second factors
and nothing else.

So the mode is gone and the route asks for a full freshFactor: true with
proofSource: "any-possession" — a second knob that widens which credentials
count as "could ever prove this", and changes nothing about the gate. A
passkey-only account now gets a real gate with the re-provable
auth.stepup.required rather than no gate at all, and the dead-end
auth.stepup.mfa_not_enrolled is reserved for an account holding nothing.

hasSecondFactorEnrolled is deliberately NOT widened. It answers a different
question, and requireFreshMfaIfEnrolled asks it before deciding whether
account deletion, the data reset, the password change, the encrypted export
and key rotation gate at all — counting a passkey there would change five
destructive actions in passing. The two predicates sit beside each other
with docblocks saying why they differ, and collapsing them turns eight
existing tests red across three files.

Recovery is named rather than assumed. On Bearer: mint an elevation with
method "passkey". On the web: sign in again, which is what stamps the
session — there is no in-page re-proof for a cookie session because the
mint endpoint is Bearer-only by design. That limit is written into the
route docblock instead of left to be discovered, and the removal's refusal
now renders its own sentence in all six locales rather than the server's
English "second-factor" prose, which was wrong for the account this card
mostly serves.

docs/api/openapi.yaml

@@ -2581,13 +2581,17 @@ paths:
         the account has no password — an account must keep at least one way in.
 
 
-        Step-up gated for accounts that can clear the gate, on the same mechanism as removing a second-factor security
-        key (DELETE /api/auth/me/mfa/webauthn/{id}). An account with a second factor enrolled — a confirmed TOTP secret
-        or a registered security key — must present a fresh factor proof: a cookie session that completed one within the
-        last five minutes, or, on Bearer, an `X-Step-Up` elevation minted at POST /api/auth/step-up against a re-proved
-        factor (a password-proved elevation is NOT enough). An account with no second factor enrolled is unaffected and
-        keeps the plain session-or-token contract, because a gate it could never satisfy would lock it out of its own
-        credential list.
+        Step-up gated, on the same mechanism and at the same strength as removing a second-factor security key (DELETE
+        /api/auth/me/mfa/webauthn/{id}). The caller must present a fresh possession proof: on the cookie path a session
+        that completed one within the last five minutes, on Bearer an `X-Step-Up` elevation minted at POST
+        /api/auth/step-up against a re-proved factor. A password-proved elevation is NOT enough.
+
+
+        A PASSKEY IS SUCH A PROOF here, unlike on the second-factor routes. An account whose only credential is a
+        passkey can satisfy this gate: a passkey login stamps the session, and POST /api/auth/step-up accepts `method:
+        "passkey"` against the account's primary passkeys. So its refusal is `meta.errorCode: auth.stepup.required` —
+        re-prove and retry — and not the dead-end `auth.stepup.mfa_not_enrolled`, which is reserved for an account
+        holding no credential this gate could ever accept.
 
 
         The elevation is spent only when the deletion is about to happen. A 404 for an unknown id, or the
@@ -2613,9 +2617,11 @@ paths:
               schema:
                 $ref: "#/components/schemas/ErrorEnvelope"
         "401":
-          description: Not authenticated, or the account has a second factor and the request carried no proof of it fresh enough
-            (`meta.errorCode` = `auth.stepup.required`). Re-prove the factor and retry — on the web by re-verifying, on
-            a native client by minting an elevation at POST /api/auth/step-up. Nothing was removed.
+          description: Not authenticated, or the request carried no fresh possession proof (`meta.errorCode` =
+            `auth.stepup.required`). Re-prove and retry — on a native client by minting an elevation at POST
+            /api/auth/step-up, on the web by signing in again, which is what stamps the session.
+            `auth.stepup.mfa_not_enrolled` is the other arm and means the account holds no credential this gate can
+            accept, so retrying will not help. Nothing was removed either way.
           content:
             application/json:
               schema: