Failed nginx config reload (bad upstream in one location) silently disables entire proxy host with no UI error

Description:

When a Proxy Host has multiple custom locations, and even one of them points to an unresolvable upstream (e.g. a stopped/renamed docker container), nginx's config test fails for the whole generated file — which is expected, since nginx validates the file as a unit. The problem is what happens next:

1. The UI shows a generic "saved" success toast, with no indication anything went wrong.
2. The failed nginx reload is logged, but only into the meta.nginx_err JSON field in the SQLite proxy_host table — it never surfaces in the UI, and it does not appear in docker logs in an obviously flagged way.
3. Because the reload failed, NPM never writes/updates the actual conf file in /data/nginx/proxy_host/. This means the entire host — including all its other, perfectly healthy locations — silently stops resolving, with clients seeing a raw TLS unrecognized name alert (from NPM's default ssl_reject_handshake catch-all) rather than any indication of what broke.

Steps to reproduce:

1. Create a Proxy Host with 2+ custom locations, each pointing to a different upstream.
2. Make one location's forward_host point to a docker hostname that isn't currently resolvable (container stopped, renamed, or not on the same network).
3. Save the host. UI shows "saved" with no warning.
4. Observe: /data/nginx/proxy_host/<id>.conf is not created/updated, and all locations on that host — including the working ones — fail with a TLS SNI rejection, not just the broken location.
5. The actual error (nginx: [emerg] host not found in upstream "...") is only discoverable by querying the SQLite proxy_host.meta column directly

Expected behavior:

• The UI should surface the nginx config test failure at save time (e.g. a toast/banner with the actual nginx -t error), instead of reporting success.
• Ideally, a single bad location upstream shouldn't be able to take down the whole host — though I guess this may be inherent to how nginx validates config files as a unit

Environment:

• jc21/nginx-proxy-manager:latest (docker)
• config generation to /data/nginx/proxy_host/

Reproduce the failure with multiple custom locations and inspect the generated file path under /data/nginx/proxy_host/, the SQLite proxy_host.meta field, and the save/reload flow. Start with the nginx -t error and trace how it is recorded and returned to the UI. Done means a failed reload is visibly reported at save time with the actual configuration error instead of a success message.