fix(auth): count a passkey as the second factor on the managed-profile acts

An account whose only strong credential is a primary passkey was refused
auth.stepup.mfa_not_enrolled on every action behind requireFreshMfa, so it
could not create, edit, hand over or delete a managed profile or manage its
guardians, although a passkey sign-in or re-proof already stamps the
session the gate reads.

requireFreshMfa now defaults to the any-possession proof source: a passkey
makes the gate reachable, and a passkey re-proof through the dialog clears
it. The refusal offers passkey in meta.methods, never the password.

hasSecondFactorEnrolled keeps its narrow meaning on purpose. It decides
whether the conditional gates apply at all (account deletion, the data
reset, the password change, the export, offering manage access, the
recent-proof branches and the native Bearer rules), so none of those
change, and password sign-in still challenges only TOTP and security keys.
The MFA-management routes keep the second-factor source. The decision and
its limits are written beside FreshFactorProofSource.

Copy, the OpenAPI description and the sharing and key-rotation docs say
"second factor or passkey" where this gate applies.

Refs #959

src/components/settings/access/__tests__/managed-profile-affordances.test.tsx

@@ -600,7 +600,7 @@ describe("ending a managed profile", () => {
       "p1",
     );
     const html = renderGatedSection();
-    expect(html).toContain("Confirm your second factor");
+    expect(html).toContain("Confirm your second factor or passkey");
     expect(html).not.toContain("The profile could not be deleted");
   });
 
@@ -616,7 +616,7 @@ describe("ending a managed profile", () => {
       "p1",
     );
     const html = renderGatedSection();
-    expect(html).toContain("does not have one yet");
+    expect(html).toContain("has neither yet");
     expect(html).toContain("Security");
   });