a way for Jenkins/Stapler to respond differently for a different domain (Host header)
No deep surgery in Stapler is really necessary, I think. Would suffice for Jenkins to define an UnprotectedRootAction to serve the static content. Then you can configure your reverse proxy to map requests to the special domain to a path prefix of the Jenkins service. For example, this is straightforward to set up in Kubernetes using the nginx-ingress controller.
As to handling non-anonymously-readable content, this can be handled in various ways. Probably something like BoundObjectTable with a one-hour expiry would suffice. (To save memory and allow links to be valid indefinitely so long as the user exists and retains access, perhaps you could support WithWellKnownURL, by encoding both a path from root to the DirectoryBrowserSupport.owner (via JENKINS-26091) and an Authentication.name in a Secret. Given a random initialization vector, I believe that is safe.)
The critical question for me is what constraints are placed on the “second domain” by the non-CSP defenses built into browsers. This very much affects whether administrators will find it practical to set up such a route: the reverse proxy is just a matter of configuration, but getting a new or expanded DNS entry typically requires extra steps. For example, if Jenkins is normally served from https://dev.mycorp.com/jenkins/ then which of the following URL prefixes would be eligible for serving static content?