when the "server channel" is enabled for a group, all group members open a channel to the server for that group. the Codename Cirrus servers send a few "connect to this peer" commands to each such member, commanding them to make some initial bootstrap connections to other members of the group that the server knows about. as you guessed, the server sends more than one "connect to this peer" command to each new member to deal with NAT/firewall issues that may prevent some P2P connections. a newly joined peer only has to connect to one other member of the group (as long as that peer is part of the connected group) in order for the new peer to learn everything it needs to know about the group topology and find its place in it (and connect to the other topologically relevant peers). the group members gossip with each other about the group's membership and topology; it is "self organizing" after the bootstrap operation.
periodically, the server will also send "connect to this peer" commands to some members in order to repair group partitions (should they occur) and keep the group connected. partitions should only occur if extremely disruptive events happen, like a very large number of peers leaving the group in a short time, or network connectivity problems (for example, BGP route flap damping could temporarily isolate peers in ISP A from those in ISP B, even though both might still be able to remain connected to Cirrus).
the bootstrap peers sent over the server channel are random (for the most part). the server has no idea which peers are publishing multicast streams and which are just subscribing. in fact, the server has no idea what the group's capabilities are (the server only sees a hash of the groupspec, not the groupspec itself) so it doesn't know if the group can be used for multicast, posting, etc., nor what its name is.