Restrict admin panel calls to Stalwart via ALB routing rules

Today, we rely on the server.http.allowed-endpoint setting in Stalwart's config to allow access to JMAP and other HTTP-based services while restricting access to the admin panel/settings paths. However, that seems somewhat unstable. We've encountered a number of problems with this feature, and it looks like the setting may be broken since sometime in the 0.12.x range (jury's still out, we're still debugging this). Given that, we should have a way of restricting this access that doesn't rely on the internal Stalwart settings, and we should have some kind of synthetic test to scream at us if it becomes available.

The issue with implementing this is that the service load balancers are NLBs (most of the services here are mail services and work over various non-HTTP protocols). We will have to make exceptions for the services that are HTTP-based so we can use ALBs for those instead. At that point, we should be able to set the same routing rules up at the ALB level, preventing the requests from reaching the server.

As for a synthetics test, we can just set up a cron-based Lambda or something simple like that which queries the public web interface or attempts a login.

We should also verify that we will still be able to log into the admin interface if we need to make settings changes. I believe this can be accomplished through the already documented method of building a bastion and setting up SSH port forwarding to it, but it needs to be tested to make sure it still works.

Start by reviewing the existing Stalwart allowed-endpoint behavior, service NLB setup, and the documented bastion with SSH port forwarding. Identify HTTP services that need ALBs, then verify that ALB rules block admin/settings paths while preserving JMAP access, a synthetic check detects exposure, and bastion access still permits administration.