Simplify authentication surface post identity-binding

[tlongwell-block]

Context

PR #293 adds enterprise identity binding (SSO/JWT → Nostr pubkey). Before it lands, worth tracking a follow-on cleanup.

Current state

The relay has accumulated multiple auth paths:

• NIP-42 — Nostr-native WebSocket auth
• JWT / enterprise SSO — corporate identity, standalone path
• NIP-98 — HTTP auth for REST bootstrap
• API tokens — scoped bearer tokens for non-interactive clients
• Dev / special-purpose paths — unverified JWT dev mode, X-Pubkey header

Problem

• Policy drift between WS and REST enforcement
• Broader attack surface than necessary
• Operator confusion: which path should users actually use?
• Cross-path complexity in enforcement logic

Proposed: converge to 3 layers

Layer	Mechanism	Purpose
1	NIP-42	Root of trust — key ownership proof
2	Enterprise identity binding	SSO/JWT binds corporate identity to pubkey (PR #293)
3	API tokens	Scoped bearer tokens for agents/bots

NIP-98 demoted to bootstrap-only, or eliminated if bootstrap moves to WS-native.

What gets removed

• Standalone SSO JWT auth path (redundant once identity binding lands)
• NIP-98 as a general auth path
• Unverified JWT dev mode (simpler dev auth exists)

Estimated impact

~2,000+ lines removable. Net effect: enterprise identity binding lands for under 1K net lines added.

Proposed sequence

1. PR feat: corporate identity binding — proxy/hybrid mode for enterprise deployments #293 — Land identity-pubkey binding
2. PR 2 — WebSocket-native bootstrap (move token minting from REST+NIP-98 to WS)
3. PR 3 — Auth path removal (mostly a deletion PR)

Non-goals

• Blossom (media auth) — out of scope
• Webhook auth — out of scope
• X-Pubkey dev header — stays, behind feature flags