A membership notice (kind:44100/44101) is relay-signed, so its id is not
bound to the reader, and it names the target, the channel and the actor.
Until now a reader who knew a notice's id could read, count or receive it
without being its target: an explicit-kind `ids` filter skipped the #p
check, and no result gate covered these kinds. With system-channel notices
stored, that would expose a hidden channel to a non-member.
Add 44100/44101 to RESULT_GATED_KINDS, the one list that the filter-level
ids exemption, reader_authorized_for_event (WS/HTTP history, push), live
fan-out (same pod and Redis) and the COUNT fallback all read. Only the
pubkey in the notice's p tag now receives it.
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Signed-off-by: Logan Johnson <loganj@squareup.com>
66a12c1755