Does it mean that former primary replica (A) will become primary replica automatically?
No, all that means is when your replica comes back into the picture, and when the Availability Group database gets back in a SYNCHRONIZED
state that it would be failover ready. That operation will not happen automatically. You indeed would have to either do this "failback" manually, or engineer a way to automate this (rather simple, let me know if you want to explore those options).
From a high-level view, your listing of steps is complete after step #3.
There is a max of 8 secondary replicas for AlwaysOn in SQL 2016, I do not believe there is a change for that in 2017
Always On Availability Groups on 2016 supports up to eight secondary replicas including one primary replica and two synchronous-commit secondary replicas (no Enhancement on this compared to SQL 2014). Also use SQL Server 2016 Always On Availability Groups to provide high availability for SQL Server databases hosted in Azure, etc. Source
In any case adding a local secondary would not add value from a SQL failover scenario. Only the instance with votes for quorum can be primary, of these there can only be three potential primaries
Another enhancement is an increase in the number of Automatic Failover partners which means you can have two more failover partners apart from the primary. In a three node scenario, if one node fails still we can have high availability with other two nodes. Source
Automatic failover requires synchronous-commit, Spreading synchronous-commit over geographic distance can have an impact on performance.
If you have a 3 node cluster (file share and other quorum considerations excepted ...), any node that can not talk to the at least one of the other two will be down. If all three loose connection, there will be no auto failover (all three will be down). If any two can talk, one of those two will be primary.
Any of the replicas that can communicate with the current primary can have asynchronous copies that are current. So if corporate goes down, one of your two stores will be primary, and you could have several stores with asynchronous read only copies.
Given your scenario you probably want the primary at corporate, and your two synchronous-commit automatic failover partners at the stores that provide the fastest and most dependable connections to corporate.
Best Answer
You should be able to see the reason automatic seeding didn't complete by looking in the SQL Server error log from the time period where you created the AG (on both the primary and secondary replicas).
One common cause for this failure is that the Availability Group doesn't have the "CREATE ANY DATABASE" permission on the secondary. To correct that, you need to go to each secondary replica and run this command:
Another place to look is the automatic seeding DMV. This query is from the MS Docs:
Check out the failure reason for clues as to why automatic seeding isn't working.
After correcting any issues you find, you can retry automatic seeding by running this code on the primary: