Standardize identity keys on npub and nsec

[jackjackbits]

Summary

• standardize human-facing and portable Nostr identities on canonical npub / nsec across the relay, CLI/admin tools, ACP/workflows, desktop, mobile, web, examples, deployment configuration, and documentation
• add shared strict identity parsing/formatting with secp256k1 x-only point validation, uniform-uppercase Bech32 compatibility, mixed-case rejection, and legacy-hex read compatibility at explicit migration/input boundaries
• make desktop and mobile display, copy, search, deep-link, snapshot, and pairing flows emit canonical npubs; pairing now verifies the transferred npub matches the nsec before persistence
• prevent nsec-shaped values, including malformed/uppercase/NIP-21 forms, from crossing relay-backed desktop search boundaries or being echoed by errors
• preserve required protocol/internal hex for signed Nostr events and tags, filters, event/blob IDs, database/cache keys, Git smart-HTTP paths, raw event JSON, and NIP-AB ephemeral session cryptography

Why

Identity representation had become inconsistent across product surfaces. Public identities were frequently rendered or exported as protocol hex, secret inputs were not always canonicalized, and some cross-layer DTOs disagreed about representation. Centralizing the boundary makes copy/paste behavior predictable, keeps desktop and mobile aligned, and closes accidental secret-disclosure paths without breaking Nostr wire compatibility.

Compatibility

• canonical output is always lowercase npub / nsec
• existing legacy hex inputs remain readable only where migration or backwards compatibility requires them
• internal protocol representations remain hex where mandated and are converted at the application boundary
• malformed identities fail closed without echoing source text

Validation

• post-rebase Rust suites passed for buzz-core, buzz-cli, buzz-acp, buzz-workflow, buzz-pairing-cli, and buzz-dev-mcp
• focused post-rebase relay npub suite: 6/6; buzz-admin test build and the SDK auth-tag example check passed
• desktop typecheck and identity/search integration suite passed; full desktop suite: 4,686/4,687, with the sole failure in an unchanged, independently reproduced join-alert timing test
• mobile focused suite: 160/160; Flutter analyzer clean; Dart formatter checked 374 files with no changes
• web and admin-web checks/tests passed
• root and nested desktop Rust formatting, desktop size/style guards, and git diff --check passed
• independent integration review found no remaining actionable P1/P2 issue

[wesbillman]

Reviewing on Wes's behalf at exact head 7c5b7fbf02534733332148766f2db839de554b1d.

One consistency/correctness issue should be fixed before merge:

web/src/shared/lib/pubkey.ts:10-18 accepts any 64-character hex value, or any decoded npub, and re-encodes it without checking that the x-coordinate lifts to a secp256k1 point. That means an off-curve value such as "ff".repeat(32) is rendered as a plausible canonical identity instead of the fail-closed "Invalid public key" sentinel. This diverges from the strict validation introduced in this same PR for Rust (crates/buzz-core/src/nostr_identity.rs), desktop/mobile, and notably admin-web/src/pubkey.ts:21-49.

The new web test does not catch this: web/src/shared/lib/pubkey.test.mjs:16-18 covers malformed text and 63 hex characters, but no structurally valid 64-hex off-curve input.

Please apply the same x-only secp256k1 validation used by admin-web before encoding both legacy hex and decoded npub values, and add an off-curve regression test. This is display-only rather than an authorization flaw, but the PR's purpose is to standardize identity parsing and fail malformed identities closed across surfaces; leaving one newly changed surface permissive defeats that contract.

Beyond this finding, the reviewed representation boundaries preserve protocol-required hex and the focused Rust identity/workflow tests passed at this exact head.

[wesbillman]

Follow-up after the independent product/compatibility review: there is an additional blocking contract issue at this same exact head.

crates/buzz-workflow/src/executor.rs:100-175 changes an existing persisted workflow template variable, {{trigger.author}}, from protocol hex to npub. Condition evaluation intentionally continues exposing the same logical author as hex through trigger_author (executor.rs:246-342). Existing workflow definitions therefore change behavior silently after upgrade, and the field now has two encodings depending on whether it is used in a template or a condition. Any existing webhook/template feeding {{trigger.author}} into a hex-key consumer breaks without a schema/version migration, compatibility mode, or warning.

Please preserve legacy {{trigger.author}} semantics and add an explicit npub variable/filter, or version and migrate existing definitions with disclosure. The added tests assert only the new behavior; they do not cover upgrading a persisted workflow whose downstream contract expects hex.

Related high-risk compatibility issue: operator/admin response fields keep existing names while switching their values in place from hex to npub (crates/buzz-relay/src/api/operator.rs:301-469 and moderation/admin response projections). Input compatibility does not preserve old response consumers. Please either version/dual-field these responses or document and demonstrate that these APIs have no stable external consumers and every shipped consumer upgrades atomically.