Have browser do domain search of unqualified hostnames

Question

On my network I've configured a DNS domain search in resolv.conf so that if you call getaddrinfo on simple hostnames it will return results for their FQDN.

$ host wiki
wiki.example.com has address 10.0.0.2
$ dig +short wiki
$ dig +short wiki.example.com
10.0.0.2

(The DNS server will not respond to unqualified names, it's all being done in libc.)

I've configured a TLS certificate on the webserver listening at https://wiki.example.com, the TLS certificate is issued by a public CA for the CN wiki.example.com.

Prior to configuring HTTPS, unqualified names could be used in the browser. So entering wiki/ into chromium (e.g.) would work. Now that TLS is configured however, browsers will complain about a common name mismatch on the certificate because they did a DNS lookup on / connected to wiki but the TLS certificate presented is for wiki.example.com.

This is unfortunate, as it's one of those security vs. usability trade-offs that doesn't really need to exist. Passing AI_CANONNAME to getaddrinfo will do a reverse DNS lookup on the address that wiki resolves to and that will (at least in some cases) return wiki.example.com. There may be mechanisms beyond getaddrinfo that could expose the domain search in a more robust way.

My question is whether there's a way to setup the OS / browsers such that they're aware of the domain search? Ideally, if chromium saw that an unqualified hostname was entered, it would append the domain before proceeding with any further logic. Then the TLS certificate would match and all would be well.

I can think of a few sub-optimal ways to achieve what I want:

1. Detect if the Host header on HTTP connections has an unqualified name and serve an HTTP redirect to the FQDN over HTTPS.
2. Issue the unqualified name as a SAN on the TLS certificate.
3. Use browser bookmarks and stop using unqualified names.
4. A "jump page" (i.e., a page full of links, hosted at a memorable location) which uses FQDNs.

The first has several problems. First is that it only works if the initial connection was HTTP, which is going the way of the dinosaur thanks to things like HSTS. Second is that it requires intimate control of the server, which is not always possible (for example, low-power IoT devices with web interfaces).

The second is not possible if certificates are issued from public CAs (which is a requirement to pass the Significant Other / house guest test).

The third is not useful due to also failing the Significant Other / house guest test.

The fourth may work, depending on how easy to convey the address of the jump page is. This is on the same order of magnitude of difficulty as conveying the WiFi name and password.