fix: accept buzz-admin hex secrets in desktop key import (#2815)

[Chessing234]

Summary

• buzz-admin generate-key now prints both hex and nsec1 forms (plus npub)
• desktop onboarding / membership-denied import accept 64-char hex secrets the same way Keys::parse / BUZZ_PRIVATE_KEY already do
• covers buzz-admin generate-key emits a hex secret that desktop onboarding rejects (expects nsec1) #2815 and the hex-paste ask on Unable to make different identity key on Windows desktop #3880

Test plan

• buzz-admin generate-key shows hex + nsec
• paste the hex into Use an existing key → Next enables and npub preview matches
• paste nsec / ncryptsec paths still work
• cd desktop && npm test -- src/shared/lib/nostrUtils.test.mjs src/features/onboarding/lib/keyImportInput.test.mjs

[Chessing234]

hex import for buzz-admin secrets — pairs with the #3880/#2815 confusion. @wesbillman if hosted/onboarding is on your plate.

[Chessing234]

@jurgenhaas @ashbrener small desktop fix for buzz-admin hex secrets on key import (#2815). easy review if you're in that area.

[ashbrener]

Read this closely because it fixes a papercut I hit yesterday: buzz-admin generate-key prints hex, the import form gated on startsWith("nsec1"), so the key it just gave me was rejected by the app. Frontend stricter than the backend for no reason. Adding npub to the generate-key output is a nice extra — I spent real time yesterday converting a hex pubkey by hand to find which identity a relay was configured with.

Two things I checked specifically, since they are where this kind of change tends to break, and both are fine:

The new "hex" kind cannot fall into a wrong branch. KeyImportKind is only ever branched on at keyImportInput.ts:123 (kind === "ncryptsec") and NostrKeyImportForm.tsx:66. Everything else routes through nsecToNpub, which now normalizes hex. No exhaustive switch to update.

Hex cannot leak into the keyring. The form submits the raw input, so I expected to find hex being persisted where the rest of the system assumes bech32 — but import_identity (commands/identity.rs:336) passes the parsed Keys object to persist_imported_identity, not the string. Storage stays normalized.

One inconsistency worth a look, inline below.

[ashbrener]

HEX_SECRET_REGEX is case-insensitive while HEX_PUBKEY_REGEX on the line above is lowercase-only. After this PR, pasting an uppercase hex secret works but an uppercase hex pubkey still does not — same file, same shape, different tolerance. parsePubkeyInput already lowercases bech32 input, so accepting uppercase hex there would be consistent with its own behaviour.

Not blocking, and arguably out of scope for this PR, but the two constants sitting adjacent with different character classes will read as an oversight later.

The same regex is also declared a second time in keyImportInput.ts. Exporting one from here and importing it there would keep them from drifting.

[Chessing234]

good catch — tip now exports a shared case-insensitive HEX_64_REGEX from nostrUtils and keyImportInput imports it, so pubkey/secret stay aligned.