feat(auth): passkeys, as a way in and as a second factor

A password and a TOTP code are both shared secrets: the server keeps something
that can be stolen from it, and the person keeps something that can be talked out
of them. A passkey is neither. The private half never leaves the device, and the
signature is bound to the origin that asked for it — so a convincing copy of the
sign-in page at another address gets a signature it cannot use.

Logging in asks for no email. The device knows which account its key belongs to,
which is not only convenience: it means the sign-in page cannot be used to find out
who has an account here. A key that verified its owner is both factors at once and
completes the login; one that only proved possession still meets the TOTP step,
exactly as a password does.

The relying party id is derived from VERDANDE_BASE_URL rather than configured
separately — a second setting that has to agree with the first is one that will
one day disagree, and the failure is a login nobody can complete. An IP address is
refused up front: no browser accepts one, and without the check the server issues
a challenge happily and the browser throws SecurityError long afterwards. The list
endpoint reports whether this deployment can offer them at all, so the interface
never shows a button that cannot work.

A challenge is stored server-side, answerable exactly once, and taken rather than
read — two requests racing the same one would both succeed, which is the shape of
a replay. A sign count that has gone backwards means the credential was cloned and
is refused rather than logged.

The Go tests cover who may reach these endpoints and that challenges are spent.
The ceremony itself needs an authenticator, so the smoke test drives Chromium's
virtual one over CDP — the only thing that can tell whether the base64url
conversions are right, since one wrong byte produces a signature that will not
verify and reads as a broken key rather than a broken encoder.

That test runs at localhost in its own context while the suite stays on the
loopback address, because WebAuthn refuses an IP and resolving localhost is slow
enough here to cost the suite minutes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

web/src/lib/locales/en.js

@@ -608,5 +608,27 @@ export const en = {
 	'done.title': 'Done',
 	'done.hint': 'Everything you have closed, newest first. Click the circle to reopen one.',
 	'done.empty': 'You have not closed anything yet.',
-	'done.unknownDay': 'No date'
+	'done.unknownDay': 'No date',
+
+	// --- passkeys ----------------------------------------------------------------------
+	'passkey.title': 'Passkeys',
+	'passkey.hint':
+		'A key on a device instead of a secret in a head. The private half never leaves the device, and the signature is bound to the address that asked for it — so a convincing copy of the sign-in page somewhere else gets nothing.',
+	'passkey.unsupported': 'This browser does not support passkeys.',
+	'passkey.none': 'No keys yet.',
+	'passkey.name': 'Name for the key',
+	'passkey.namePlaceholder': 'e.g. my laptop',
+	'passkey.add': 'Add a key',
+	'passkey.registering': 'Waiting for the device…',
+	'passkey.remove': 'Remove',
+	'passkey.removeQuestion': 'Remove "{name}"? That device cannot sign in with it afterwards.',
+	'passkey.bothFactors': 'both factors',
+	'passkey.possessionOnly': 'possession only — the code is still required',
+	'passkey.lastUsed': 'last used {when}',
+	'passkey.neverUsed': 'never used',
+	'passkey.signIn': 'Sign in with a passkey',
+	'passkey.signingIn': 'Waiting for the device…',
+
+	'passkey.unavailable':
+		'Passkeys cannot be used here — either this browser does not support them, or the server’s address is an IP rather than a domain name, which no authenticator will accept.'
 };