feat(auth): add token-bound step-up elevations for second-factor management

Second-factor management has been cookie-only since v1.23. The gate is right:
a Bearer token is a credential whose provenance the server cannot see, and
tearing down a second factor must not be reachable from the weaker of an
interactive login and a value pasted into a script. What was missing was never
Bearer access to those routes — it was a way to say, over a transport with no
session row, that the human holding this device just re-proved a factor.

An elevation is that proof. It is minted only against a re-proved account
password or primary passkey, bound to the exact token that re-proved, single-use
via a conditional UPDATE, five-minute-lived to match the cookie path's step-up
window, and stored hashed. A stolen token mints nothing; a second token cannot
redeem another's elevation; a password change drops every one the account holds.

requireMfaManagementAuth is the one gate the management routes share. On a
cookie session it delegates to the original helpers unchanged, so the web flow
runs the code it always did. requireAdmin stays cookie-only and out of reach.

src/lib/validations/mfa.ts

@@ -57,7 +57,7 @@ export const mfaVerifySchema = z
  * `@simplewebauthn/server`; this just pins the envelope shape for OpenAPI and
  * the runtime `safeParse`.
  */
-const webauthnCredentialSchema = z
+export const webauthnCredentialSchema = z
   .object({
     id: z.string(),
     rawId: z.string(),

src/lib/validations/step-up.ts

@@ -0,0 +1,38 @@
+/**
+ * Request schemas for the step-up elevation surface. Single-sourced here so the
+ * runtime `safeParse` and the OpenAPI registry describe the identical wire
+ * contract.
+ */
+import { z } from "zod/v4";
+import { webauthnCredentialSchema } from "@/lib/validations/mfa";
+
+/**
+ * Re-prove a factor to mint an elevation.
+ *
+ * Two accepted proofs, discriminated on `method`:
+ *   - `password` — the account password. Unavailable on an account that signed
+ *     in through OIDC SSO and never set one; such an account uses the passkey
+ *     arm, or manages its second factor on the web.
+ *   - `passkey` — an assertion against a primary passkey the device already
+ *     holds, begun at `/api/auth/step-up/options`.
+ *
+ * The password is length-bounded so a body cap is not the only thing standing
+ * between a caller and an unbounded Argon2id verify.
+ */
+export const stepUpMintSchema = z
+  .discriminatedUnion("method", [
+    z.object({
+      method: z.literal("password"),
+      password: z.string().min(1).max(512),
+    }),
+    z.object({
+      method: z.literal("passkey"),
+      challengeId: z.string().min(1),
+      credential: webauthnCredentialSchema,
+    }),
+  ])
+  .meta({
+    id: "StepUpMintRequest",
+    description:
+      "Re-prove the account password or a primary passkey to mint a single-use, token-bound step-up elevation.",
+  });