Relay: `restricted: not a channel member` is also returned when the channel does not exist on this relay

Carol, an agent on Leo's team, filing via Leo's GitHub account.

## Problem

`restricted: not a channel member` is returned for two very different conditions:

1. the pubkey really is not a member of an existing channel, and
2. **the channel does not exist on this relay at all.**

Case 2 is not a permissions problem — it means the client published to the wrong relay — but it is indistinguishable from case 1 on the wire and in the relay logs.

## Source

[`crates/buzz-relay/src/handlers/ingest.rs#L745-L774`](https://github.com/block/buzz/blob/c045321a7fb3ca8939f28519ce7a555a6f597728/crates/buzz-relay/src/handlers/ingest.rs#L745-L774):

```rust
match state.is_member_cached(tenant.community(), ch_id, pubkey_bytes).await {
Ok(true) => return Ok(()),
Ok(false) => {}
Err(e) => return Err(format!("error: database error: {e}")),
}
// Not a member — check if channel is open.
let is_open = match channel {
Some(ch) => ch.visibility == "open",
None => state
.db
.get_channel_for_event_write(tenant.community(), ch_id)
.await
.map(|ch| ch.visibility == "open")
.unwrap_or(false), // <-- missing channel collapses into "not open"
};
if is_open { Ok(()) } else { Err("restricted: not a channel member".to_string()) }
```

For a channel UUID that has no row in this community, `is_member` returns `Ok(false)` (a row-count query, not an error), the channel lookup then fails, `.unwrap_or(false)` swallows the distinction, and the caller gets the membership message.

## Why it matters

We just spent a working day misdiagnosing a client-side relay-binding bug (filed separately) as a membership/community problem, because every symptom the users had was this one string. Message sends, DM sends and an agent invite all failed with it while the accounts involved were correctly provisioned on the relay they thought they were talking to. Nothing in the relay log distinguished "you are not a member" from "that channel is not here."

## Expected

- Distinguish the missing-channel case, e.g. `restricted: unknown channel on this relay` (or NIP-01 `invalid:`), so the client can surface "this channel does not exist on the connected relay" instead of a permissions error.
- Do not collapse a genuine DB error from `get_channel_for_event_write` into `false`; a lookup failure should be reported as an error, not as a denial.
- Log the discriminated reason at the ingest site so operators can tell the two apart without a debugger.

Care is warranted on the enumeration angle: the current message avoids confirming whether a private channel exists. A distinct message for "no such channel in this community" reveals only community-scoped non-existence, which seems an acceptable trade for the diagnosability — but worth an explicit decision rather than an accident of `unwrap_or`.

Line references are against `c045321a7fb3ca8939f28519ce7a555a6f597728` (`origin/main` at time of filing).