feat(storage): support deleting backends and improve admin UI

- Implement storage backend deletion, which automatically resets default storage settings and user-specific overrides when a backend is removed.
- Add unit tests covering the delete action and its cleanup side effects.
- Improve admin UI responsiveness, fixing table scrolling, flex wrapping, and text truncation for long storage backend names.
- Update security documentation to clarify trusted proxy configurations and explain how trusted proxies are protected from automatic bans.

SECURITY_PROXY.md

@@ -24,10 +24,10 @@ public internet.
 ## Trusted Proxies
 
 For stricter deployments, set `WARPBOX_TRUSTED_PROXIES` to the IPs or CIDR
-ranges that are allowed to provide forwarded headers:
+ranges that are allowed to provide forwarded headers. Use proxy IPs only.
 
 ```env
-WARPBOX_TRUSTED_PROXIES=127.0.0.1,::1,172.16.0.0/12,10.0.0.0/8
+WARPBOX_TRUSTED_PROXIES=127.0.0.1,::1,172.30.0.1
 ```
 
 When this value is set, Warpbox trusts `X-Forwarded-For` and `X-Real-IP` only
@@ -37,9 +37,15 @@ directly from any other IP ignore forwarded headers and use the socket address.
 Recommended values:
 
 - Same-host Caddy with systemd: `127.0.0.1,::1`
-- Docker bridge networks: add the bridge CIDR, often `172.16.0.0/12`
+- Docker/Podman bridge gateway: add the exact gateway IP, for example `172.30.0.1`
+- Docker bridge networks: use a CIDR such as `172.16.0.0/12` only if the exact gateway changes often
 - Private reverse-proxy networks: add the exact private CIDR used by the proxy
 
+Warpbox prefers the first public address in `X-Forwarded-For` when a trusted
+proxy sends a chain. Loopback addresses and trusted proxy addresses are also
+protected from manual and automatic bans so a bad header setup cannot ban Caddy,
+the container gateway, or Warpbox itself.
+
 ## Direct Exposure
 
 If you expose Warpbox directly without Caddy, either leave