fix: stop the API key field showing a secret it has discarded

[yujiezhang-ops]

Fixes #119. The issue described two paths where a typed key is dropped; the first turned out to be worse than reported.

The field displayed a key it had already thrown away

ProviderKeyPage renders SecureKeyField with a hardcoded value="" (:140), and the effect that syncs the draft depends on that prop — which never changes. So changeProvider → clearApiKey() emptied keyRef and flipped hasApiKey to false, but the input went on displaying what the user typed for the previous Provider.

I verified this with a throwaway probe rather than trusting the read: after a re-render with value="", the input still held sk-typed.

The user-visible state is worse than "the key is silently discarded" (what #119 says). The field shows a plausible-looking key, canContinue is false because hasApiKey was cleared, and the Continue button is disabled with nothing on screen explaining why. The screen contradicts itself.

resetKey drives the clear instead. It skips its own first run — the Provider editor mounts this component with a saved key already in value, and clearing there would discard it. Revealed state resets too, so the next Provider's field does not open unmasked.

The second path

continueSetup returned early on providerHasKey alone, before reading the ref, so a key typed in this session was dropped with no save call and no message while the page advanced as though it had worked. Now it checks both.

Verification

• 304 passed (39 files), 5 new
• Reverted each fix independently: dropping the reset effect fails 2, restoring the early return fails 1
• pnpm run build, pnpm run test:e2e (6 passed)

The SaveKey no-op noted in #119 is left alone — Store.SaveKey returning nil for an empty key is correct for its callers; the issue there was only that this page could reach it with nothing to save, which is now fixed upstream of it.

🤖 Generated with Claude Code