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.

src/__tests__/step-up-elevation-guard.test.ts

@@ -94,9 +94,12 @@ function callers(exportName: string, moduleRe: RegExp): string[] {
  * That one is `DELETE /api/auth/passkeys/{id}`. A passkey is the PRIMARY
  * sign-in credential, and it sat behind a plain session while the second-factor
  * key beside it demanded a fresh proof — the softer gate on the more valuable
- * credential. It joins the set on `freshFactor: "if-enrolled"`, so an account
- * with a second factor pays the full price and an account without one keeps the
- * contract it had rather than losing the ability to remove its own credential.
+ * credential. It joins the set on the same `freshFactor: true` as the rest,
+ * differing only in `proofSource: "any-possession"` — which widens the
+ * REACHABILITY pre-check to count a primary passkey and does not soften the gate
+ * itself. A passkey-only account clears it by re-proving that passkey: on Bearer
+ * through the mint's `passkey` method, on the web through a fresh sign-in, which
+ * is what stamps `mfaVerifiedAt`.
  *
  * The widening that admits is real and bounded: an elevation minted against a
  * re-proved factor can now also remove a passkey. That is the same class of act