Define and enforce a trust/auth model for all RPCs

Severity: critical (product decision).

### Summary

None of the four RPCs (`SendNote`, `FetchNotes`, `StreamNotes`, `Stats`) have any authentication or authorization. The server is built with only CORS, grpc-web, a global concurrency limit, and a request timeout (`crates/node/src/node/grpc/mod.rs:117-126`); there is no interceptor, API key, or mTLS anywhere. gRPC reflection additionally advertises the full API surface (`mod.rs:103-109`).

This is not necessarily a bug — an open, privacy-by-tag relay may be the intended design — but it is currently implicit. It needs to be an explicit, documented decision, because every abuse-resistance control in the meta-issue depends on the answer.

### Options

- **Open relay by design:** then rate limiting (#117), storage quotas (#118), and note validation (#116) become mandatory compensating controls, and this should be stated in the operator docs and proto.
- **Gated:** add an auth interceptor (API key / mTLS) at least for `SendNote` and `Stats`.

### Acceptance

- The trust model is documented (README + operator docs + proto comments).
- If open-by-design, the compensating-control issues are linked as blockers to GA.

Related: #44, #47.

---
Part of #114.

Start by reading the gRPC server setup in crates/node/src/node/grpc/mod.rs lines 103-126. Review the four RPC methods (SendNote, FetchNotes, StreamNotes, Stats) and the existing interceptors. The decision on the trust model (open relay vs. gated) must be made first. If implementing auth, look at adding an interceptor for API keys or mTLS, focusing on SendNote and Stats. Document the model in README, operator docs, and proto comments.

Vom Indexierungsmodell aus dem Issue-Text verfasst.