The reason the documentation states that automatic failover is not supported is that there are post-failover tasks that must be carried out to ensure the Report Server is completely online. See this section for information on exactly what tasks need to be completed. Essentially it boils down to needing to stop the SQL Agent on the old primary and restart the Report Server service.
I am thinking to create the listener first with 2ips for those multi
subnet so that we can use same while installing reporting services and
point the listener name in instance and it's report server database to
it so that it is aware of primary replica even after failover. Is my
above understanding correct? Is that how it's suppose to work?
Yes, build your AG and configure the listener first, then when you'r configuring the report server you can point it at the listener.
Secondly, document says automatic failover is not supported even when
I use sync mode between N1 and N2 ? Is that true? And why would that
be the case only with SSRs? Also if it is , can we automate the
faiover or does it have to be manual everytime since I am thinking
data source application string can use the option multi subnet
failover = true ?
There seems to be some crossover here where you're talking about report data sources and Report Server databases. RS databases are the databases used by report server to manage and maintain the report server. They're typically named ReportServer and ReportServerTempDB. These databases do not support automatic failover because there are post-failover tasks you must complete to bring the service back to a 100% normal state.
These tasks can be automated through scripts easily enough, but that is is what the documentation means by not supported. For your report data sources, these only need AG specific parameters in the connection string (such as MultiSubnetFailover or ApplicationIntent) if the source databases are in an AG as well. If they are then adding those keys to your connection strings will ensure the reports continue working post-failover. They should handle failover automatically.
Something to note is this line from the documentation:
The use of MultiSubnetFailover, with the report server databases, is not supported.
What this means for you, given you have a multi-subnet cluster, is that you should set the RegisterAllProvidersIP setting to 0. This setting is 1 by default and means that each IP assigned to the listener is registered in DNS. If MultiSubnetFailover is enabled, the client will try to connect to each IP in parallel and return the connection from the first IP that responds. As this setting is not supported by the RS service for connections to the RS databases, after a failover you will likely encounter timeouts trying to connect.
The solution is to set RegisterAllProvidersIP to 0 and set a low TTL for that host record. This ensures that only the active IP is registered with DNS for the listener, and after failover the new IP is registered with DNS. This means new connections to the listener use the correct IP and you avoid timeouts.