Availability Groups automatic failover is not so automatic
You have a quorum issue in this setup.  There are only two participants in the cluster:

SQL1
SQL2

If SQL1 goes down, there's no way for SQL2 to know that it should be the primary.  For all SQL2 knows, the network has gone down and SQL1 is still operating as the primary.  Thus, SQL2 goes to the RESOLVING state (it's not sure what to do).  This is to prevent a &quot;split brain&quot; scenario.
For a two-node cluster, generally you need to add a File Share Witness as a resource in the WSFC cluster.  This will allow the remaining instance, SQL2, to establish quorum with the FSW, and take over as the primary.
Additionally, the behavior of AGs is not to automatically fail back to the &quot;original primary&quot; as soon as it's back up.  Automatic failover is only in the case of an outage on the current primary, it's not intended to &quot;automatically fail back.&quot;

Note that the other scenario you described, stopping the primary cluster node, is not how you want your AGs to failover.  Don't do that:

Do not use the Failover Cluster Manager to manipulate availability groups, for example:

Do not add or remove resources in the clustered service (resource group) for the availability group.

Do not change any availability group properties, such as the possible owners and preferred owners. These properties are set automatically by the availability group.

Do not use the Failover Cluster Manager to move availability groups to different nodes or to fail over availability groups. The Failover Cluster Manager is not aware of the synchronization status of the availability replicas, and doing so can lead to extended downtime. You must use Transact-SQL or SQL Server Management Studio.