In a little bit of a face-palm moment, I found and corrected the problem with my HTTPS redirection attempts.

Oone of the domain's subdirectories has its own .htaccess file with its own rewrite rules within. Further, it didn't have the correct "redirect to HTTPS" rule, so when URLs entered that path, the .htacceess file found within would fail to redirect the web page (except when other rules were hit, but that changed the path and page, not the host,  port, or scheme).

I corrected this oversight in two ways.

First, I added the correct redirect rule to the .htaccess file in that path. It worked splendidly. It is the case that this is the only other .htaccess file in the site, so for now the problem is solved. It occurred to me that in the future I may add an application that has its own .htaccess or even just add another one to another folder for some reason (like a renamed file), and that would reintroduce the problem. I need a better solution that compels the root of the domains to behave.

As an experiment, I then changed my Apache config so that the named virtual host for the domains' port 80 mapping went to an empty document root folder. Then there were no .htaccess files in the path, and the rewrite rules in the Apache configuration were used, the browser redirected to the HTTPS virtual host, and all of the other mappings again worked.

So now all of the vanity domains on any address' port 80 have this simple rule, so that all of the traffic is now sent to https://jekewa.com, as this page does.

RewriteCond %{https} off [or]
RewriteCond %{http_host} !^jekewa.com$ [nc]
RewriteRule ^(.*) https://jekewa.com/$1 [r=301]

(Sorry about that $1 line above turning into a link; I can't find how to suppress that in the blog software...)

Now the only trouble I have is if I add a query string; it doesn't redirect. Evidently http://jkwarren.info?some=string doesn't match ^(.*) and it isn't redirecting.