New user onboarding has multiple show-stoppers

I signed up today with a new account, 'morrildl'. I started, but did not complete, the 'add a PGP key' flow in the browser. Specifically, when I got to the step where it offers to let you use the keybase binary, I switched to that flow, since it seemed cleaner/safer than the curl approach.

Because it was the first client and I was looking to add my GPG key, I couldn't use GPG to authenticate, so I used account passphrase. When I tried to add a key via 'keybase pgp select', it failed because I use a yubikey and thus the binary couldn't export my private key(!) for whatever nefarious machinations it wants it for.

So I returned to the web UI, to add my key that way via the curl method, after all. However, the site refuses to let you do this if you have extant clients, including a paper key client. So I went into account settings and deleted them all; this caused the "add a PGP key" link to reappear, so I went back into the curl-based flow.

However, the curl method returns error 908 (also known as issue #982):
Code: 908
Name: KEY_NEED_REVOKE
Description: You need to delete your active key before uploading a new one

Note again that as of this writing I have never successfully added a key.

Because at this point it was clear that everything was broken, for the lulz I went through the "generate a key for me" flow in the web UI, twice. Neither attempt actually attached a key to my account.

At this point:
1) I can not create new clients, because I had already used passphrase login once, had deleted the paper key client to regain access to web key add UI, and did not have a PGP key added to authenticate directly.
2) I can not add a PGP key, by any means.
3) The web UI tells me I have no key attached.
4) The API tells me (via both curl and 'keybase login') that I need to delete the "active" key before it will let me upload one or create a client.

I next did the "recover passphrase" flow, hoping the reset would fix the above. It did not; I am still in that state. (For instance, 'keybase login' with account passphrase says "ERROR Passphrase provision is not possible since you have at least one provisioned device or pgp key already")

There are of course multiple bugs here:
- The keybase binary should not be attempting to export my private key, ever, for any reason, full stop. Demonstrably you don't need it, as evidenced by the 'curl' version of the flow. If your philosophy is that you prefer to make native calls directly into libgcrypt instead of shelling out to gpg proper, I still don't care: I don't trust your code and I'm not interested in reviewing it. For all I know, your binary is (hypothetically) simultaneously vulnerable to Heartbleed and doesn't check HTTPS server certs, exposing my private key to a MITM. As far as I'm concerned, my Yubikey has successfully defended me from an attack, here.
- You have a backend data consistency error, insofar as your API server and web UI don't agree on whether I have an active key linked to my account. Accordingly, I can't fix it by deleting the key, etc.
- Issue #982 appears unresolved (and indeed, unacknowledged), insofar as it appears to have just happened to me too. That is, it appears that aborting an 'add key' flow left my account in an unrecoverably broken state.
- Your "reset account" flow doesn't fully reset an account. (i.e. I am still stuck in this 'phantom key' state.)
- The web site & API really really really ought not to let the user delete the paper key client, if it's the only such client or last client on the account. Or at the very least, display a much scarier warning on delete.
- The keybase client doesn't properly support sequestered keys on smartcards, but this is sort of a secondary consequence of the first bug above.

Start by reproducing the reported onboarding sequence across the web UI, API, keybase binary, curl-based key upload, and account reset flow, including the Yubikey case and an aborted add-key attempt. Done means the reported phantom-key state, inconsistent UI/API state, unusable client recovery, and unsafe key-handling behavior are separately understood and covered by verified fixes or follow-up issues.

Written by the indexing model from the issue text.