Summary. vector-core implements private channels, but vector_sdk exposes
none of it, so a bot added to a private channel silently stops responding with no
error and no diagnosable signal. Verified against vector_sdk 0.5.0 and 0.6.0.

What happened. Our bot lives in an encrypted community and answers every
message in its home channel, resolved by name. The community owner converted that
channel to a private one and added the bot as a member. The bot has not responded
since. It is running, connected, and polling normally.

What we found.

vector-core 0.4.0 already has full private-channel support, including
create_private_channel, and two behaviours that exactly describe our symptom:

• follow_control_records_a_new_private_channel_keyless_and_unreadable
• a_private_channel_subscribes_to_its_own_chat_plane

So a follower records the new private channel with no key and cannot read it, and
private channels use a separate chat plane. Both are presumably deliberate.

vector_sdk 0.5.0 and 0.6.0 contain ZERO private-channel references. grep -c
for "private" across src returns 10 in both, and every hit is about private
bots (invite whitelisting) or prose describing Vector as a private messenger.
The whole channel API surface is a single pub fn channel. The only public API
added between 0.5.0 and 0.6.0 is download_attachment_from.

In our bot's local cache the consequence is visible: community_edition_heads
holds 13 channels while community_channels holds 7, so six channels have edition
heads and no resolvable metadata. Every row in community_channels has
private = 0, including the channel literally named "private". Our home-channel
resolution reads list_communities() and matches on channels[].name, so a
keyless channel with no name can never be matched, and the bot keeps listening on
the now-unused public channel.

Why this is worth an SDK change rather than a doc note. The failure is silent
and indistinguishable from "nobody has talked to the bot yet". There is no error,
no warning, and no API that would let a bot detect it. From the operator's side
the bot is simply mute.

What would fix it, roughly in order of usefulness:

1. A way for a bot to receive and store a private-channel key, so membership
   granted by an admin actually takes effect.
2. A way to enumerate private channels the bot is a member of, including ones it
   cannot yet decrypt, so tooling can tell "not a member" from "member without a
   key".
3. Failing both, a surfaced signal when a control event records a channel the bot
   cannot read, so the condition is at least diagnosable rather than silent.

Environment. vector_sdk 0.5.0 and 0.6.0, vector-core 0.4.0 and 0.5.0,
Rust, Linux. Reproducible by adding a bot to a private channel and sending a
message it would otherwise answer.