Desktop: backup-file restore accepts raw .key/nsec but renders no Continue action

**Describe the bug**

The first-run **Restore from a backup file** dialog accepts a raw `.key` file containing a valid `nsec1...` private key. It successfully parses the file and displays **Nostr identity found** with the derived public identifier, but renders no Continue/Next action. The user is stranded in a dialog that has positively recognized the identity.

**Steps to reproduce**

1. Start Buzz Desktop onboarding.
2. Choose **Use an existing key**.
3. Open **Restore from a backup file**.
4. Select a small `.key` text file whose first non-empty line is a valid `nsec1...` value.
5. Observe **Nostr identity found** and the derived public identifier.
6. Observe that no Continue/Next button is rendered; only closing the dialog is possible.

**Expected behavior**

Either:

- allow the recognized raw key to continue through the normal identity-import action; or
- reject `.key`/raw `nsec` files in this encrypted-backup-only dialog and direct the user to the normal **Private key** import path.

Recognizing the identity while providing no forward action is a dead end.

**Version and platform**

- Buzz version: Desktop 0.5.6
- OS: Windows 11 PRO x64

**Logs / additional context**

No private-key, public-key, or screenshot data is included.

The bug is also structurally present in current `main`:

- `MachineOnboardingFlow` opens `NostrKeyImportForm` with `mode="backup"`.
- The shared file input accepts `.key,.ncryptsec,text/plain`.
- `handleFiles` loads the first non-empty line, including a valid raw `nsec`.
- A valid raw key renders the **Nostr identity found** preview.
- The submit CTA is rendered only when `mode === "key" || isPasswordStage`.
- A raw `nsec` in `mode="backup"` is not a password stage, so neither condition is true and no CTA appears.

Workaround: close the backup dialog, paste the same `nsec` into the normal **Private key** field, and continue there.