Re: Bugbot comment on non-atomic regeneration — Already addressed in follow-up commits:
- ade4dfed — Reordered to create-first-then-revoke, so if create fails the old key is untouched
- 72f8d44a —
setNewKey()called immediately after creation so the user can always copy the new key even if revoke fails - 2e764091 — Added
oldKeyRevokedstate tracking with conditional messaging — shows accurate revocation status
The flow is now safe: create new key → capture it in UI → revoke old key. Worst case on partial failure: user has two working keys (safe, can manually revoke the old one).