Feature Request: Service-to-service authentication for the Buzz HTTP bridge

**Motivation**

Buzz’s HTTP bridge provides useful authenticated operations including event
publication, event queries, counts, webhooks, media, and Git endpoints.
Protected operations use NIP-98 HTTP authentication, which requires the calling
service to hold a Nostr private key and generate a signed `kind:27235`
Nostr HTTP-auth event for every request.

This is appropriate for Nostr-native clients, but it prevents many standard
automation services, server-side applications, workflow platforms, and
enterprise integrations from safely using Buzz’s existing HTTP bridge. These
systems commonly support API keys, OAuth 2.0, client credentials, or signed
JWT/service-account authentication, but do not support NIP-98 event signing.

At present, users must build and operate a separate custom signing adapter that
holds a Nostr private key, authenticates the upstream service, creates a
NIP-98 signature, forwards the request to Buzz, and returns the response. This
adds security risk, deployment complexity, credential-management overhead, and
an additional service to maintain.

**Proposed solution**

Add an officially supported service-to-service authentication option for the
existing Buzz HTTP bridge.

The feature should allow a machine client to authenticate using a standard,
documented service authentication method, while Buzz maps that credential to a
dedicated Buzz/Nostr service identity and continues to enforce the normal
community, membership, channel, and permission model.

Possible supported methods could include one or more of:

- Scoped API tokens.
- OAuth 2.0 client-credentials flow.
- Signed JWT/service-account authentication.

The implementation should:

- Work with existing generic HTTP bridge operations, including `POST /events`,
`POST /query`, and `POST /count`, rather than introducing a separate
conventional CRUD API.
- Map each service credential to one dedicated Buzz/Nostr identity.
- Enforce least-privilege, community membership, channel permissions, and
operation-specific scopes.
- Allow credentials to be created, named, scoped, rotated, expired, revoked,
and audited.
- Keep NIP-98 support unchanged for native Nostr clients.
- Ensure external services never need direct access to the mapped identity’s
Nostr private key.
- Record an auditable service identity, credential identifier, operation,
community, and outcome for each authenticated bridge request.
- Provide deployment and secret-storage guidance for self-hosted Buzz
installations.

**Alternatives considered**

1. **Continue using NIP-98 directly**

This remains the right option for Nostr-native applications, but it requires
every external service to implement NIP-98 event construction and signing,
and to hold a Nostr private key.

2. **Build a private NIP-98 signing adapter**

A separate adapter can accept standard authentication, create NIP-98-signed
requests, and forward them to Buzz. However, every deployment must install,
secure, monitor, update, and maintain this extra service and its private key.

3. **Add conventional REST CRUD endpoints**

Endpoints such as `/messages` or `/channels` would be less aligned with
Buzz’s Nostr-first, signed-event architecture. Supporting standard
service-to-service authentication on the existing HTTP bridge preserves the
current event model while solving the integration problem.

4. **Use only WebSocket/Nostr clients**

WebSocket remains appropriate for Nostr-native real-time subscriptions, but
it does not provide a practical standard-authentication path for many
server-to-server integrations.

**Additional context**

Buzz’s relay and HTTP bridge are based on signed Nostr events. The existing
bridge already provides operations including:

```text
POST /events
POST /query
POST /count
POST /hooks/{id}
PUT /media/upload
GET /media/{...}
GET/POST /git/{...}
```

The request is not to replace NIP-98 or redesign Buzz as a conventional REST
CRUD application. It is to add a secure, officially supported
service-to-service authentication route for the existing HTTP bridge, so that
standard automation and server-side integrations can use Buzz without requiring
a separate NIP-98 signing service.

Start by reviewing the existing HTTP bridge entry points for POST /events, POST /query, POST /count, hooks, media, and Git operations. Define which standard authentication method and credential lifecycle are supported, then verify that mapped identities, scopes, permissions, auditing, key isolation, and unchanged NIP-98 behavior are covered.

Written by the indexing model from the issue text.