First, when using AGs, you generally are not using a clustered instance of SQL Server, you are using multiple standalone SQL Servers. You are able to technically connect to each individual SQL Server in the Windows Cluster Separately. Each having their own configuration and resources.
Secondly, each group has its own name in AD as a computer object and its own IP address. These are registered in DNS. These are different than the cluster name. The listener name is a special object to route traffic based on incoming query type. For instance, if you configured your AG to use a secondary node for read only queries, the listener name is what routes that query to the secondary node, not the cluster group. Backups are also attached to that listener name for routing traffic from the primary to the secondary node.
If you are monitoring AG health, it will be based off of the listener name/object, not the cluster name. It is possible to have a 3 node windows cluster, but only have an AG involving 2 nodes. The cluster name would not properly handle that.
Adding further complexity to this question. With SQL 2016, you have distributed availability groups which uses separate clusters on different networks or domains. Those separate clusters are clusters all to them selves and are only joined via the listener name for failover purposes.
Lastly, if you chose to extend your AG to Azure, you will need to use the listener when connecting to the "active" database so your query can route to the appropriate node. The cluster resource name does not know about the Azure secondary node.
This is a difficult scenario to truly handle. I would probably start with running a job on your secondary replica that checks the state of all the databases, and should it become primary for one of them then performs the ALTER AVAILABILITY GROUP [AG] FAILOVER; command for all of the others.
The biggest challenge with this is also running jobs on the primary, and taking care to not accidentally try to fail one of those databases back. You could manage this by checking the AlwaysOn extended event session and looking for failovers there, and do not do work if the database was failed away (as the most recent captured event), this way you don't end up bouncing the databases around all over the place.
You can use sys.fn_hadr_is_primary_replica to check and see if any particular database is the primary on your system.
Best Answer
Correct, this is the expected behavior as the listener only "points" you to the instance where the primary databases for that availability group are currently located. It does not scope permissions or any other securable.
No, not in the way you're thinking due to what I states above that a listener is not a securable. If you only want an application to "see" a specific set of databases then set the permissions to those databases only. If you scope the permissions in this way, they will not show up under SSMS but the login will have access to them (assuming the login is not the database owner [this is not the same as the db_owner role]).