Add TOTP (authenticator app) as an alternative to passkeys for setup and login

[BenjaminPrice]

Problem

EmDash currently requires a passkey to create the first admin user during setup, and passkey is the primary login method afterward. Passkeys are great when they work, but they cause real friction for
some users: inconsistent browser/OS support, Bluetooth handshake failures on some platforms, and general unfamiliarity. When passkey setup fails on first run, the deployer is stuck with no fallback.

For ongoing login we offer magic link as a fallback, but a chunk of users would prefer not to depend on email for daily sign-in either.

Proposal

Add TOTP (RFC 6238, the "scan this QR with Google Authenticator / 1Password / Authy / Bitwarden" pattern) as an alternative auth method that works at both:

1. First-run setup — user picks Passkey or Authenticator app on the admin step
2. Ongoing login — third option alongside Passkey and Magic link

Passkeys remain fully supported and stay the recommended default. TOTP is opt-in per user, with recovery codes for the lost-phone case.

Why TOTP fits EmDash

• Zero external dependencies. No email backend, no OAuth provider, no special browser APIs. Just a form and a QR code.
• Works on every device with an authenticator app, which most users already have.
• Familiar pattern from existing 2FA flows, so the learning curve is roughly zero.
• Slots into the existing @oslojs ecosystem we already use for crypto/encoding/webauthn (@oslojs/otp is the sibling package), so no new trust assumptions and no new dependency tree.

Alternatives considered

Magic link at setup time

The natural question: why not just use the existing magic link flow for first-run setup? Because there's no email backend yet. Email plugins are configured after the admin user logs in for the
first time. Magic link works fine post-setup, but at T=0 there's nothing to send through.

Bootstrap token printed to the terminal (Ghost / Gitea / Vaultwarden pattern)

Print a one-time setup token to stdout on first run, admin pastes it in the browser. Simple and proven. Ruled out because we can't assume the deployer and the admin are the same person. A
managed-hosting provider might deploy EmDash for a customer who never sees the terminal output. Anything that requires console access at first-run time excludes that scenario.

Just improve passkey error messages

Probably worth doing regardless, but it doesn't help the users whose passkey UX is broken at the platform level (BLE issues, browser bugs, corporate device policies). Better errors make a bad situation
more diagnosable, they don't unblock it.

Related Issue(s)

#21

[ascorbic]

I am aware of the need for alternative login methods for first run (which is why were working on pluggable auth #398 ), but TOTP is designed for 2FA, and is not suitable for use as a single factor login. Let's have a discussion about other options for first run. I think the local setup console approach is possible, and in deployed cases use a third party provider, but I'm open to suggestions.