ha-mcp: Add-on settings and policy routes are reachable without authentication at the bare root path

Summary

### Summary

In add-on mode, the ha-mcp settings UI routes are mounted both under the MCP secret path **and** at the bare root of the published port (`:9583`), so Home Assistant ingress can serve the "Open Web UI" button. The root-mounted routes perform no authentication — no secret, no `Origin` check, no CSRF token — so any client that can reach `:9583` without the MCP secret can invoke them.

### Affected configurations

Home Assistant **add-on** installations (`host_network: true` with port `9583` published), v7.6.0 and earlier. Docker and standalone installs are **not** affected — there the settings routes are mounted only under the secret path.

Root-mounted routes in affected versions: tool visibility (`/api/settings/tools` GET/POST), feature flags (`/api/settings/features` GET/POST), the auto-backup suite (`/api/settings/backups…` incl. restore/delete, and `/api/settings/backup-config`), add-on restart (`/api/settings/restart`), and — when the opt-in Tool Security Policies feature is enabled — the approval-policy API (`/api/policy/config` GET/PUT, `/api/policy/approve`, `/api/policy/deny`, …).

### Impact

Without authentication, a caller that reaches `:9583` — a peer on the local network, a reverse proxy/tunnel that forwards the bare root path (e.g. a whole-host Cloudflared config), or a CSRF `POST` from a page open in a LAN browser — can read or change which MCP tools are exposed, toggle feature flags, list/view/restore/delete backups, restart the add-on, and (with Tool Security Policies enabled) read and rewrite the approval policy, disabling the human-approval gate on gated tools.

There is **no** access to Home Assistant data, entities, or credentials, and no code execution. All effects are confined to the add-on's own configuration and lifecycle and are recoverable. The primary (same-LAN) vector is within the add-on's documented trusted-network model; remote reachability requires the operator to have reverse-proxied the bare port.

### Proof of concept

With the add-on running and reachable on `:9583`, from any host that can reach the port without the secret:

``` GET /api/settings/tools -> 200 (read tool config, no auth) POST /api/settings/tools {"states":{}} -> 200 (rewrite tool config, no auth / no CSRF token) POST /api/settings/restart -> 200 (restart the add-on) ```

The MCP endpoint itself remains correctly protected by the secret path.

### Patch

Fixed in PR homeassistant-ai/ha-mcp#1508 (merged to `master`): the root-mounted add-on routes are restricted to Home Assistant ingress, which always originates from the Supervisor (`172.30.32.2`); every other caller receives `403`. Direct and remote access continue to use the settings UI under the MCP secret path (`…/<secret>/settings`), so the "Open Web UI" button, Cloudflared, and the Webhook Proxy add-on are unaffected.

The fix will ship in the next stable add-on release. If you'd rather have it now, it is already on the dev channel (add-on dev build ` 7.6.0.dev393` or later) — optional; there's no need to switch channels just for this, it is a fairly low risk surface and only exposes the web UI for addon mode only.

### Severity

`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L` = 6.4 (Moderate). Confidentiality impact is None — tool config and backups are not secrets or credentials; integrity and availability impacts are Low — configuration changes and an add-on restart are recoverable.

### Credit

Reported by @bharat.