[FEATURE] Per-host Web Endpoints — open a host's web UI directly or via an on-demand SSH tunnel

Title

Per-host Web Endpoints — open a host's web UI directly or through an on-demand SSH tunnel

Platform

N/A

Is it related to an issue?

Most hosts people manage in Termix also serve a web UI — Proxmox on 8006, a
NAS or router admin page, a container dashboard, an internal app. Today
reaching one means leaving Termix: switch to a browser, remember the
scheme/port/path, type it in. And when the UI is bound only to the host's
loopback or its LAN (the common case for admin panels), there is no address to
type at all — you first hand-build an ssh -L forward, then browse to the
local port. Termix already holds the SSH connection and the host's details, but
gives you no way to use them to reach that web UI.

The Solution

Let a host declare its web UIs, and open them from the sidebar.

• Declare per host. In the host editor, a "Web UI" section lets you add up
  to a handful of endpoints, each with a scheme (http/https), port, and
  path, plus a label. This mirrors the existing per-host tunnels editor.
• Two access modes per endpoint:
  • Direct — open the host's own address (https://<host>:<port><path>), for
    a UI already reachable from where you are.
  • Tunnel — Termix establishes an SSH port-forward to the endpoint's port on
    the host on demand, and opens the local end. This reaches UIs bound only to
    the host's loopback or LAN, with no manual ssh -L. The forward is named,
    idle-closed after ten minutes, and re-opened on next use.
• Two render modes: open in the user's browser, or in an in-app iframe tab.
• Exposed vs. loopback bind for tunnels: the forward binds loopback by
  default; an explicit opt-in binds all interfaces so a Docker deployment can
  publish the port.

Security is a first-class part of the design, not an afterthought. Cookies are
keyed by host and ignore the port, so a web UI reached at the very host string
serving Termix would be handed Termix's session cookie (and could set one back).
The feature refuses to open a tunnel in a browser deployment unless it can reach
the forward at a different loopback spelling than the page is served from, and
falls back with an actionable message rather than framing a leaking or dead
page. On the desktop app the session is Bearer-only with no cookie in the jar,
and per-origin certificate allowances for ignoreCert endpoints are momentary
and scoped, never global.

Additional Context

Scope covers the host editor UI, the sidebar entry (one "Web UI" item that
expands to a picker when a host has several), the in-app tab, the tunnel
manager's on-demand open/idle-close, and threading the config through the host
read/write paths and the SQLite schema. Works in the web/Docker deployment and
the desktop app.

Start by tracing the existing per-host tunnels editor, host read/write paths, and SQLite schema, then review the sidebar and tunnel manager entry points. The work spans the host editor, sidebar picker, in-app tab, on-demand tunnel lifecycle, web/Docker deployment, and desktop app. Done means configured endpoints support the requested direct and tunnel access modes, render modes, lifecycle behavior, and security constraints.