You described your situation really well but the following part isn’t making sense (unless I’m not reading you correctly, or I’m more clueless about snaps than I thought):
I’ve always thought snapd looks and acts like a container but isn’t a container in real life since its packages still use and rely on the system. In which case your Nextcloud installation should be using Apache server already installed by Virtualmin, preferrably on standard ports 80 and 443 (mostly 443 since Nextcloud basically won’t run over http). i.e., There shouldn’t be any difference in how Nextcloud is installed whether with snapd, with Nextcloud’s PHP installer or with a traditional tarball. IMO, in an environment like Virtualmin’s with so many moving parts, snap packages are useful only when there’s no other alternative; with Nextcloud there’s an easier alternative.
For the sub-domain format you’re using consider Virtualmin’s sub-server feature for Nextcloud if you aren’t using it already. This way, Nextcloud will have its own virtualhost config and DNS zone, and if SSL is issued separately from the parent domain renewals may go more smoothly with only one name to validate.
If you’re going to plow ahead with snaps try switching ports and everything else back to normal. If that’s not feasible you’ll want to get familiar with Nextcloud’s main .htaccess file in its root directory. There are strict security headers and redirects that may be obstacles to SSL and other things if anything about the web server isn’t standard stuff.