fix(relay): push system channel events to a lease that names them (#8517)

🤖
## Summary
Mobile clients can now get push notifications for a system channel, but
only when they ask for that channel by its ID. Before this change, the
relay never sent push for system channels, even when a client asked for
one directly.

System channels are channels the app uses for its own purposes (for
example, agent attention). They are hidden from clients that do not know
about them. #8507 made push use the same visibility rule as normal
reads: a push subscription sees a system channel, or any channel type
added later, only if its filter names that channel ID in `#h`. With that
rule, an older client can never get system channel pushes by accident.
The extra "never push system channels" rule in NIP-CL now only blocks
clients that ask on purpose, such as a future Live Activities
subscription. This PR removes that special case.

### Details
- `push_runtime.rs`: system channels now follow the same rule as other
named-only channel types. The relay still checks membership before it
sends a wake.
- `NamedOnlyChannels::is_system` had no other caller, so it is removed.
- NIP-CL and NOSTR.md now describe the shared rule instead of the ban.
- No behavior change for current clients. They do not name system
channels in their push subscriptions.

### Related issue
Follow-up to #8507 (see
https://github.com/block/buzz/pull/8507#issuecomment-6316180106).

### Testing
- `named_only_channel_pushes_only_to_a_filter_that_names_it` now expects
a wake for a system channel named by `#h`. It also checks that a broad
filter still gets no wake, and that a non-member still gets no wake.
- `cargo test -p buzz-relay --lib push_runtime`, `cargo clippy -p
buzz-relay --all-targets -D warnings`, and `cargo fmt --check` pass.

Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>

NOSTR.md

@@ -156,10 +156,11 @@ out unless they ask for it:
   combine with OR, so `#t:["system", <label>]` does not mean "a system
   channel with this label".
 
-Push notifications skip system channels. Every kind:44100/44101 membership
-notification carries its channel type as `t`, and a filter without `#t` sees
-only the legacy types, so system channel notices reach only a filter with
-`#t:["system"]` (see NIP-CL).
+Push notifications use the same rule: a lease filter pushes events from a
+system channel only when its `#h` names that channel. Every kind:44100/44101
+membership notification carries its channel type as `t`, and a filter without
+`#t` sees only the legacy types, so system channel notices reach only a filter
+with `#t:["system"]` (see NIP-CL).
 
 Events are stored **channel-scoped** so access control applies — private channel member lists are
 only visible to members. Discover groups via historical REQ: