Explain the execution flow of a private Realtime broadcast channel authorized by Row Level Security?

A private Realtime channel starts the same way a public one does — a client calls supabase.channel('room-42', { config: { private: true } }) and attempts to subscribe — but before any messages flow, the Realtime server checks whether that connection's JWT is authorized for this specific channel, rather than allowing any authenticated client onto any channel name.

1. The client establishes a WebSocket connection to Realtime, presenting its JWT.
2. On a subscribe attempt to a private channel, Realtime queries a Postgres function (or checks a realtime.channels-linked RLS policy) to determine whether this user is authorized for that channel name.
3. If the check passes, the subscription is accepted and the client starts receiving Broadcast or Presence events published to that channel; if it fails, the subscription is rejected before any data is sent.
4. Every subsequent message published to the channel is delivered only to connections that passed this authorization step, rather than to every WebSocket connected to the server.

This differs from the plain "Postgres Changes" channel type, where authorization is enforced per-row via table RLS on every change event; a private broadcast/presence channel instead authorizes at the channel-subscription level, once, up front — useful for scenarios like a chat room or collaborative document where the "row" being protected isn't a single table row but an entire logical room.