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/app/api/auth/passkeys/[id]/__tests__/route.test.ts

@@ -167,24 +167,26 @@ describe("PATCH /api/auth/passkeys/{id} — the rename refusal", () => {
 });
 
 /**
- * The removal's gate, and what it must NOT be.
+ * The removal's gate, and the one option that keeps it from being a dead end.
  *
  * A passkey is the primary sign-in credential and it came off a plain session,
  * while the second-factor key next door demanded a fresh proof. The route now
- * asks the same gate the second-factor removal asks — but with
- * `freshFactor: "if-enrolled"`, not `true`. That distinction is the whole
- * design: `true` refuses an account with no second factor outright, and most
- * accounts holding a passkey have nothing else enrolled, so `true` would take
- * their own credential list away from them.
+ * asks the same gate that one asks, at the same strength — `freshFactor: true`,
+ * not a softer mode. What it adds is `proofSource: "any-possession"`, and that
+ * is the whole design: the gate's reachability pre-check counts second factors,
+ * and a passkey-only account holds none, so the default question would have
+ * refused `mfa_not_enrolled` to an account that was holding the proof the gate
+ * accepts. A passkey stamps `mfaVerifiedAt` on login and is a `passkey`-method
+ * mint arm; the pre-check simply was not asking about it.
  *
  * The gate itself is behavioural and lives against a real database in
  * `tests/integration/step-up-elevation.test.ts` (E14). What is pinned here is
- * what this file can prove without one: the route asks for the right mode, and
- * it spends the proof only when it is actually about to delete.
+ * what this file can prove without one: the route asks both halves of the right
+ * question, and it spends the proof only when it is about to delete.
  *
- * Mutation check: change the option to `true` and the first case goes red; move
- * `commitElevation()` above the ownership check and the third goes red; drop it
- * altogether and the second goes red.
+ * Mutation check: drop the `proofSource` option and the first case goes red;
+ * move `commitElevation()` above the ownership check and the third goes red;
+ * drop it altogether and the second goes red.
  */
 describe("DELETE /api/auth/passkeys/{id} — the removal's gate", () => {
   const mkDelete = () =>
@@ -192,7 +194,7 @@ describe("DELETE /api/auth/passkeys/{id} — the removal's gate", () => {
       method: "DELETE",
     });
 
-  it("asks for the step-up gate in its if-enrolled mode", async () => {
+  it("asks for a full step-up, against any possession factor", async () => {
     vi.mocked(prisma.passkey.findUnique).mockResolvedValue({
       id: "pk-1",
       userId: USER.id,
@@ -204,10 +206,12 @@ describe("DELETE /api/auth/passkeys/{id} — the removal's gate", () => {
     await (DELETE as unknown as Handler)(mkDelete(), { params });
 
     expect(requireMfaManagementAuth).toHaveBeenCalledWith({
-      freshFactor: "if-enrolled",
+      freshFactor: true,
+      proofSource: "any-possession",
     });
-    // Not `true`: that arm refuses an account with no second factor, which is
-    // a lockout on this route rather than a safeguard.
+    // Not the bare second-factor question: it would refuse `mfa_not_enrolled`
+    // to a passkey-only account, which is every account this route mostly
+    // serves, over a proof it was already holding.
     expect(requireMfaManagementAuth).not.toHaveBeenCalledWith({
       freshFactor: true,
     });

src/app/api/auth/passkeys/[id]/route.ts

@@ -76,28 +76,45 @@ export const PATCH = apiHandler(
  * nothing about a hijacked session quietly stripping the credentials the owner
  * signs in with. So this route goes through `requireMfaManagementAuth` too.
  *
- * Two consequences worth stating rather than discovering:
+ * Two things about the gate that are easy to get wrong, and are not:
  *
  *   BEARER IS NOT REFUSED. `requireFreshMfa` is cookie-only, so a gate built on
  *   it alone would have told the native client to go and use the website. The
  *   gate this route borrows has a Bearer arm — a step-up elevation minted
- *   against a re-proved factor, exactly what the app already does to remove a
- *   security key — so the app keeps the capability and pays the same price the
- *   web pays.
+ *   against a re-proved factor — and `passkey` is both one of the mint's methods
+ *   and one of `FRESH_FACTOR_METHODS`, so the app re-proves the passkey it
+ *   already holds and pays the same price the web pays.
  *
- *   AN ACCOUNT WITH NO SECOND FACTOR IS NOT LOCKED OUT. `freshFactor: true`
- *   refuses those outright, which is right for a route that manages a second
- *   factor and wrong here: most accounts with a passkey have nothing else
- *   enrolled, and they would lose the ability to remove their own credential.
- *   `"if-enrolled"` gates the accounts that can clear the gate and leaves the
- *   rest exactly where they were.
+ *   A PASSKEY-ONLY ACCOUNT CAN CLEAR THIS GATE, which is why the gate is the
+ *   plain `freshFactor: true` and not something softer. It reads like a lockout
+ *   — most accounts holding a passkey enrol no second factor beside it — and it
+ *   is not, because a passkey IS a possession factor here, as this codebase
+ *   already says in three places: a passkey login stamps `Session.mfaVerifiedAt`
+ *   (`/api/auth/passkey/login-verify`, v1.23 M-review M1), `passkey` sits in
+ *   `FRESH_FACTOR_METHODS`, and `resolveMfaEnrollmentRequired` counts a primary
+ *   passkey as satisfying the enforcement policy outright. The only thing that
+ *   would have refused such an account is the reachability pre-check inside
+ *   `requireFreshMfa`, which counts second factors and nothing else;
+ *   `proofSource: "any-possession"` asks the question this route actually means.
+ *
+ * WHAT A REFUSED PERSON DOES NEXT. On Bearer: mint an elevation with
+ * `method: "passkey"` at `POST /api/auth/step-up`. On the web: sign in again,
+ * which is what every other step-up refusal in this app tells people and what a
+ * passkey login already does. The web has no dedicated in-page re-proof for a
+ * live cookie session — the mint endpoint is Bearer-only by design — so the
+ * recovery there is a fresh sign-in rather than a dialog. That is a real limit,
+ * it is named here rather than discovered, and it is the same one the
+ * second-factor removal beside this route already lives with.
  */
 export const DELETE = apiHandler(
   async (
     request: NextRequest,
     { params }: { params: Promise<{ id: string }> },
   ) => {
-    const auth = await requireMfaManagementAuth({ freshFactor: "if-enrolled" });
+    const auth = await requireMfaManagementAuth({
+      freshFactor: true,
+      proofSource: "any-possession",
+    });
     const { user } = auth;
 
     const { id } = await params;