No enforceable phishing-resistant-only login mode, and magic link is on by default

[Bccorb]

Part of #155. Session 7.

Problem

The default login policy is
login_methods: ['passkey', 'magic_link']
(src/config/systemConfig.defaults.ts:10).

Magic links are not phishing-resistant. A deployment left on defaults, sold as
phishing-resistant authentication, ships with a phishing-susceptible fallback
enabled.

passkey_login_fallback_enabled can suppress fallback when a user already has a
passkey (src/services/loginPolicyService.ts),
but there is no single enforceable "phishing-resistant only" mode, and no way to
produce evidence of one for an auditor.

Why it matters

This is the core product claim. An agency being assessed against Maryland's Local
Cyber Assessment Tool, or answering a cyber insurance questionnaire, needs to state
what its authentication actually enforces. Right now the honest answer for a default
deployment is weaker than the pitch.

What to do

• Add an explicit phishing-resistant-only mode that disables magic link and OTP
  login as continuation methods, not merely as fallbacks
• Make the mode queryable, so the posture report and the coverage report in the
  sibling issue can state it as fact
• Consider whether the default for a new deployment should change, which is a
  product positioning decision

Acceptance

• A deployment in phishing-resistant-only mode refuses every non phishing-resistant
  login path
• The mode is visible in configuration and reportable
• Existing deployments are unaffected unless they opt in

Freeze status

Exception 4, and it underpins the NIST SP 800-63B AAL claims discussed in
CERTIFICATION-READINESS.md.