The quorum is probably staying up because of dynamic quorum.
Applies to 2016 and above as well:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj612870(v=ws.11)?redirectedfrom=MSDN#BKMK_dynamic
Note the FSW is not used in an odd numbered Cluster.
If you want and can run the DAG in Site B, have at it, but not sure of the value of only two servers in one DC versus three in the other, if one of those in Site B goes down during the maint outage, you are now down to one server and lose all the advantages of the DAG.
Since you have this planned, why not take advantage of that and build and a third server in SITE B, add DB copies to it and then set the FSW to a server in Site B.
Now you have three copies in that site and a FSW local to the site ( Since you now will have 6 DAG members the FSW is relevant)
That way, if you somehow had an issue with a server in Site B during the outage, you will still have 2 copies and redundancy.
Then, move the quorum and active copies to Site B.
Once the maint is complete is Site A, bring the network back up first and then each MBX server in Site A, then move the quorum back to Site A if desired
You can also set the FSW back to Site A as well.
https://learn.microsoft.com/en-us/exchange/high-availability/manage-ha/manage-dags?view=exchserver-2019#dag-witness-server-and-witness-directory
https://markgossa.blogspot.com/2016/01/move-file-share-witness-exchange-2016.html
With DAC mode, this should prevent split brain problems. You will to also probably stop any backups if you are doing them during the outage.
Once all the cluster is back up and happy, expect a alot of time to replay all the logs generated and that has to be copied over from Site B to Site A.
Dont move the quorum or copies back till everything shows clear and healthy