feat: nostr identity endpoints

[escapedcat]

Nostr identity endpoints (parity follow-up to #89)

Follow-up to the merged Nostr sign-in endpoint (#89). That PR let a Nostr key
mint a token; this one exposes the linked identity and lets an existing
account manage its Nostr link. All new surface is REST under
/v4/users/me; no new DB migration.

What's in here

Expose the linked npub

• GET /v4/users/me (MeResponse) gains npub: Option<String> (bech32, or
  null). Flows into the create-token and update-username responses too via
  the shared struct.
• The RPC whoami Res gets the same npub field, so the two "who am I"
  surfaces stay in sync.

Manage the link (new sub-resource /v4/users/me/nostr)

• GET → { npub } — read the current link (Bearer only).
• DELETE → clears it, idempotent 200 { npub: null } (Bearer only — clearing
  your own link needs no proof).
• PUT → links/replaces the pubkey on the account. Returns 200 { npub };
  400 if the npub is already linked to a different account; idempotent re-link
  by the same account → 200.

user.npub already exists (migration 98); select_by_npub/set_npub already
existed (the latter was #[allow(dead_code)], now used). No migration, no
schema.sql change.

Decision that needs your eyes: the PUT dual-credential header

PUT /v4/users/me/nostr needs two credentials at once — a Bearer token
(which account) and a NIP-98 signature (proof you control the pubkey).
Both the Auth and NostrAuth extractors read the Authorization header, so
they can't share it. I resolved this by carrying the proof on a dedicated
header:

Authorization:        Bearer <token>
X-Nostr-Authorization: Nostr <base64(event)>   # signs u=<base>/v4/users/me/nostr,
method PUT

Implementation: factored the NIP-98 verification in nostr_auth.rs into a
shared verified_npub(req, header) helper, and added a thin NostrProof
extractor that reads X-Nostr-Authorization (same ApiBaseUrl-pinned
verification as NostrAuth). The request body stays empty, so there's no
SHA-256 body-binding gap. If you'd prefer a different header name or
mechanism, this is the piece to flag — happy to change it.

(Deliberately not the #83 approach of a nostr_event body field — nip98.rs
warns body endpoints need body-hash binding, and the client-supplied url
param there was the bot-flagged weakness.)

Conflict check is application-level (no unique index yet)

The PUT conflict check is select_by_npub → compare → set_npub, which has a
documented TOCTOU window: two concurrent PUTs linking the same npub to
different accounts could both pass the check. This is intentional for now and
called out in a code comment — the partial unique index on user.npub (your
in-flight work, closed as #93) is what closes it, after which a set_npub
UNIQUE violation could map to 400. I did not add that index or a migration
here, to stay off your toes.

Heads-up (not touched): stale comment in the merged sign-in code

src/rest/v4/nostr.rs (merged in #89) has a doc-comment claiming the npub
unique index comes "from migration 101" — but on master, 101 is the
access_token.import_origins migration and no such index exists. The
recovery branch it describes is currently dormant. Flagging only; left it
alone since it's coupled to whenever the index actually lands.

Out of scope

• create_api_key_with_nostr admin RPC — redundant with POST /v4/auth/nostr.
• The user.npub unique index / any migration — yours.
• RPC-style link/update/remove (the Add Nostr auth via NIP-98 for identity linking and token retrieval #83 paradigm) — superseded by this REST
  sub-resource.