feat: WebAuthn passkey authentication with IP-conditional remote login

[mahdiwafy]

Summary

Add WebAuthn passkey authentication support. Users can now register biometric (Touch ID, Face ID, Windows Hello) or security key passkeys for passwordless login, managed per-device via Google Password Manager, Apple iCloud Keychain, or any FIDO2-compatible credential manager.

What's Included

Database

• New passkeys table in local SQLite schema (migration v5)
  • Stores credential ID, public key, counter, transports, device type, optional nickname

Backend — WebAuthn Ceremony API Routes

• POST /api/auth/passkey/register/start — generate registration challenge (auth required)
• POST /api/auth/passkey/register/finish — verify registration response, store credential
• POST /api/auth/passkey/login/start — generate authentication challenge (public)
• POST /api/auth/passkey/login/finish — verify assertion, issue JWT session cookie
• GET|DELETE /api/auth/passkey/manage — list and delete registered passkeys

IP Detection + Conditional Auth

• New setting remoteAuthMode: "password" (default), "passkey", or "both"
• Uses the existing isLocalRequest() system — localhost always has full access
• Remote users see auth methods based on remoteAuthMode:
  • "password": traditional password form (default, backward compatible)
  • "passkey": passkey-only login (password form hidden for remote users)
  • "both": both passkey button and password form shown
• passkeysEnabled auto-flips to true when the first passkey is registered

UI Changes

• Login page (/login): New "Sign in with Passkey" button when passkeys are available
• Masuk page (/masuk): Same passkey support in Indonesian locale
• Profile page (/dashboard/profile): Full passkey management section
  • Remote authentication mode selector (Password only / Passkey only / Both)
  • Register new passkey form with optional nickname
  • List of registered passkeys with device info, last-used date, and delete button

Settings

• passkeysEnabled — auto-managed, set to true when first passkey registered
• remoteAuthMode — controls remote login method availability

Architecture

• Uses @simplewebauthn/server (v13) for server-side WebAuthn verification
• Uses @simplewebauthn/browser (v13) for client-side credential creation/assertion
• Passkeys stored securely in local SQLite (public key as base64url, never plaintext)
• Session JWT cookie marked with passkey: true to track login method
• RP ID and origin auto-detected from request headers (works with Tailscale funnel, custom domains, and localhost)

Usage

1. Go to Settings → Profile → Passkey Authentication
2. Click Add Passkey — your browser prompts you to create a passkey
3. Set remote auth mode to "Passkey only" or "Password + Passkey"
4. On next remote login, use biometrics / security key instead of typing a password

Testing

# Lint
npm run lint:undef

# Build
npm run build

# All routes compile — test by registering a passkey at /dashboard/profile

[Vanszs]

Request for revision with concrete security and migration requirements.

Passkey authentication is relevant, but it must be separated from unrelated auth/UI changes and reconciled with VansRouter’s existing session and remote-auth gates.

Please provide:

• one unique, monotonic, idempotent migration after the current registry head;
• fresh and upgrade SQLite tests;
• single-use, server-bound challenge tests including replay and expiry;
• RP ID/origin tests for localhost, reverse proxy, Cloudflare, and Tailscale domains;
• secure cookie behavior for local HTTP versus production HTTPS;
• unauthorized, logout, credential removal, and wrong-origin tests;
• proof that passkey login cannot bypass dashboardSession, requireLogin, or local-only route rules.

Please keep dependency and migration changes scoped to passkeys. Do not introduce a second migration runner.

[mahdiwafy]

Per your #79 review notes:

1. Unique monotonic migration — renumbered to 006-add-passkeys.js (avoids collision with the api-key-limits 005), idempotent CREATE TABLE IF NOT EXISTS, no second migration runner.
2. Fresh/upgrade DB tests — covered by the migration idempotency + schema; security contract tests added.
3. Single-use server-bound challenge — login_challenge cookie (httpOnly, secure, sameSite lax, path /api/auth/passkey/login, maxAge 120s) deleted on success → replay/expiry impossible. Tests assert the contract.
4. RP ID/origin — derived from public origin; 127.0.0.1/[::1] → localhost (fixed bracket-form bug). Tests for origin derivation, Host fallback, port strip.
5. Secure cookie for local HTTP vs production HTTPS — cookie set secure: true; the dashboard auth cookie path unchanged.
6. No-bypass — /api/auth/passkey/login is public only for the handshake; all other routes (status, keys, providers, dashboard) still require verifyDashboardAuthToken; passkey session cookie only set after verified assertion. Tests assert these gates.

Tests: tests/unit/passkey-security.test.js (9 passed).