passkey support

[jpike88]

What this PR does

This PR adds support for passkey dialog flow detection. It just presses authenticate, and leaves the user to use their passkey authentication, which on success will log the user in.

Checklist

• make clean && make && make test passes (full unit suite green)
• No credentials, account numbers, or PII in the diff
• CHANGELOG.md updated under the next version's heading
• docs/OBSERVABILITY.md updated (if touching ALERT tokens, /health, or env vars listed there)
• docs/FROM_IBC.md updated (if changing anything that maps to an IBC key)
• docs/UPGRADING.md gets a new ### vX.Y.Z section if the change is operator-visible
• Commit messages imperative ("fix X", not "fixed X" or "WIP")

See CONTRIBUTING.md for the
"Adding a new..." walkthroughs covering the most common extension
points (ALERT tokens, dialog handlers, env vars, IBC-key mappings).

[jpike88]

@code-hustler-ft3d can you please confirm this script works for your existing 2fa flow... (I am using passless to provide the passkey virtual device). I have confirmed that it works for me

[code-hustler-ft3d]

Thanks — and to answer your question directly: yes, it leaves the existing 2FA flows intact. I didn't want to say that from reading alone, so I drove the real handle_2fa against a mock agent on your commit (4f8047b). Four cases, sixteen assertions, all green, each also asserting your handler actually ran rather than being bypassed:

• normal TOTP dialog, TOTP configured → code still typed, Authenticate never pressed
• passkey dialog, TOTP configured → Authenticate pressed, nothing typed
• passkey dialog, no TOTP → Authenticate pressed
• IB Key push loop, normal dialog, no TOTP → dialog left alone, success via the API port — that's the loop your diff edits and the path the Controller relaunches Gateway after its own daily auto-restart, racing install4j's restarter — turns a session-preserving restart into a cold login (and daily 2FA) #23 reporter runs

Your full suite passes on that commit too (322). And the code is careful in ways I appreciated: no new agent commands, no coordinates, refusing an ambiguous multi-window match, re-reading the dialog before the raw-name retry, stripping CR/LF because the protocol is line-oriented. You also fixed a latent bug of ours — the post-relogin loop would have called the TOTP generator with an empty secret in IB Key mode.

On scope: this is the arrangement I said in #22 I'd revisit if someone got an out-of-tree signer working. You did, with passless. Pressing Authenticate and leaving the ceremony to your authenticator is driving Gateway's dialog, not holding a key. I'm in.

What I've added rather than ask you to do, on pr29/followups in this repo, on top of your three commits:

1. An opt-in gate, PASSKEY_AUTHENTICATE=yes. With it unset, a passkey prompt fails loudly with the same reason string v0.8.1 emits (plus a remediation= hint), so every existing deployment is byte-for-byte unchanged. I'm adding this because I have no passkey account to verify against — you do — and it makes the ⚠️ in the compatibility table honest. It's one if; push back if you think it's wrong.
2. 13 tests — the four flows above as unit tests, the pure helper, and the env parsing. 344 pass on the branch, rebased on current main.
3. Docs: README reframed from "not supported" to "the controller presses Authenticate, you supply the authenticator"; the new ALERT_2FA_FAILED reason in OBSERVABILITY; an UPGRADING entry. (The checklist ticked those boxes but the diff didn't touch them — no action needed from you now.)
4. Changelog: your line landed inside [0.9.0], which shipped 2026-09-07; it's now a full [Unreleased] entry crediting you.
5. A comment where the handler returns True on an accepted click, saying plainly that 2FA reports success before the ceremony completes and a silent authenticator surfaces as the API-port timeout.

Two ways to get those onto this PR — your call:

• Tick "Allow edits by maintainers" on the PR sidebar and I'll push the commit straight onto your branch. Simplest.
• Or bring your branch up to date first (main moved since you branched — fix(config): verify the Lock and Exit schedule actually stuck #30 landed), then git fetch upstream pr29/followups && git cherry-pick eebaebd and push yourself.

Then one thing only you can do: re-run your live passless login with PASSKEY_AUTHENTICATE=yes set and confirm it still works with the gate in. I'm approving the CI run now so the PR shows a status (first-time fork contributions need that here); I'll merge once you confirm the live run.

[jpike88]

I have updated my branch as requested, and I have tested the update to date branch with the PASSKEY_AUTHENTICATE=yes flag present, and it appears to work fine :)

[code-hustler-ft3d]

Merged — thank you. Before merging I checked that your branch is byte-identical to the one I tested, and the full suite passes on your exact commit (352).

It's on main with the gate, tests and docs, and ships in the next release. Your live run with PASSKEY_AUTHENTICATE=yes is the real-account validation behind it, and the README credits you for it.

If a Gateway update or a passless change stops the prompt from matching, the signal will be ALERT_2FA_FAILED reason="passkey Authenticate lookup failed". Open an issue with that line and the dialog dump that follows it, and I'll take a look.