[FEATURE] Enhance Autoconf and Bunkerweb to allow a more distributed architecture

### What's needed and why?

Hi, I have been playing around with trying to get bunkerweb to work in a distributed architecture and have found some limitations with the autoconf service and others, which I believe a few modifications will help resolve. It would make bunkerweb a lot more flexible and resilient in a enterprise space.

To explain the architecture, I have a VPS which is connected to my network via tailscale subnet routing. The intention is to expose my services via the VPS (Like a tunnel) rather than my network due to lack of ipv4 and CGNAT. The services I want to expose to the public will be accessed via the bunkerweb in the VPS, however when I'm at home I want the network to go via the DMZ I have at home, so all the traffic says internally.

The architecture that I would like to achieve somewhat is below:

How it work:
_1. Allow autoconf to work on any number of docker hosts (not necessarily with bunkerweb container on those hosts)_
Benefit:
- Allow us run autoconf on any docker host and use labels to deploy the service on bunkerweb worker on other hosts. For example I can spin up immich on seperate docker host in a different vlan and with the use of autoconf and labels, the service will be automatically configured on the bunkerweb works in the DMZ. (Assuming firewalls are already in place)

Current Limitation:
- It appears that autoconf is expecting to have a bunkerweb instance running on the same docker host. I can't run it without a bunkerweb instance on the host.
- It seems that I can only have one autoconf per scheduler. As per my diagram I tried to run two autoconfs, one in DMZ Home Network and another in the VPS, with bunkerweb instances on both. I did this to try and register both instances of bunkerweb using autoconf. This seems to break things, when I go into the Web UI, only the last bunkerweb instance seems to be registered, the earliest one is overwritten. So in the instance list you will only ever see 1 instance of type container. (I can raise this as a bug, if this is not expected to happen).

_2. Allow scheduler to deploy to a cluster of bunkerweb workers_
Benefit:
- This currently works and is awesome feature, currently the one autoconf I can get going is able to register new services and deploy them to both bunkerwebs in the two DMZ's. It really saves a lot of time and is great for a CI/CD setup.
- As mentioned in point 1, it seems that when autoconf register a bunkerweb instance with the scheduler, it uses the container name. This doesn't work if the autoconf is on a seperate host to the scheduler. I got around this by making the bunkerweb container name the hostname

Enhancement:
- It would be a fantastic enhancement if we can get a bunkerweb to be part of multiple namespaces, this way I could define the VPS bunkerweb with a namespace of DMZ-EXT and the internal one, DMZ-EXT,DMZ-INT. This would allow me to define whether a service should be deployed to just one or both bunkerwebs, all via autoconf. There may be services that I want to have accessible from the internet and others just internally.

_3. Allow everything to be monitored from Web UI._
Benefit:
- If the above enhancements are made, it would be great if the UI can then show the namespaces that the instances are part of. Also show the namespaces that the services are part of. It would allow someone to see what is happening all from the web ui.
- One more enhancement if allowing multiple instances to exist would be seperate out the metrics by the instance, this way you can see if one instance is getting hit harder than expected or not. (Assists with troubleshooting Load Balancers)

I think the architecture above will work really great in enterprise space as well it allows for multiple instances of bunkerweb to exist with autoconf and work well with CI/CD for deployment of services. However it would be a shame to see it paywalled from the open source community. However I understand that there must be ways to support and fund the development of this product. If the above does get implemented but paywalled, it would be great for open source, if we can have a node/worker limit for community edition where you can have (3 bunkerweb workers, unlimited autoconf host) or (3 bunkerweb workers, 5 autoconf hosts) and then tiered worker limits for the pro version.

### Implementations ideas (optional)

_1. Allow autoconf to work on any number of docker hosts (not necessarily with bunkerweb container on those hosts)_
- Allow a environment variable AUTOCONF_STANDALONE: yes (default: no), which will remove the check to wait for an instance to come up.

_2. Allow scheduler to deploy to a cluster of bunkerweb workers_
- Allow bunkeweb to specify its hostname via the label "bunkerweb.INSTANCE=", rather than yes. This will allow us to specify to the scheduler how to reach the bunkerweb instance when discovered by autoconf.
- Change the label bunkerweb.NAMESPACE to bunkerweb.NAMESPACES and allow for multiple namespaces. The scheduler will deploy the service based on the namespaces the bunkerweb instance is part of.

_3. Allow everything to be monitored from Web UI._
- I would assume this needs new columns to be able to include and track on the namespace.
- The UI metrics will need to new columns to allow filtering by instance.

I can provide the docker-compose files that I am using currently and also the docker-compose file of what the end state I would expect to see if the above is implemented.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start by tracing the autoconf service, scheduler registration and deployment flow, then inspect the Docker Compose configuration and the Web UI entry points for instances and metrics. The requested work spans standalone autoconf hosts, reachable worker identity, multiple namespaces, and per-instance monitoring; done means these distributed deployments are supported and visible in the UI.

Written by the indexing model from the issue text.