feat(proxy): per-proxy status hosts + HTTPS interstitial permit-gate

[0pcom]

Two related features on the embedded-web-proxy surface (dmsg_web, skynet_web, and the skysocks-client tunnel they chain to). Design + first working increment; read-only MVP with explicit seams for route control. See docs/proxy-status-and-interstitial.md.

1. Interstitial over HTTPS

The branded "building a route over the mesh…" interstitial (pkg/proxyinterstitial) rides a locally-terminated TLS session (TLS MITM) for HTTPS targets, since a raw-TLS tunnel can't carry an HTML page. TLS termination uses a name-constrained local CA (pkg/skynetca) that can only mint leaves for .skynet/.dmsg.

The live bug: the HTTPS-interstitial path attempted a mint for every TLS-port dial failure — including clearnet HTTPS forwarded to the upstream skysocks-client, which the CA can never cover — producing a host does not match permitted suffix error on every such request.

Fix: skynetca.Permits(minter, host) — a non-breaking optional interface (HostPermitter, implemented by CachedMinter) that reports whether the CA can cover a host without minting. Both resolving proxies now gate the HTTPS-interstitial mint on it:

• .skynet/.dmsg HTTPS → interstitial renders over TLS as intended;
• clearnet HTTPS (un-MITM-able by a name-constrained CA) → falls through cleanly to the real error, no per-request log spam.

The interstitial page also gained a footer deep-link to the surface's status host.

2. Per-proxy status hosts

Each proxy serves a read-only diagnostic page at a reserved, well-known host through itself, mirroring the existing in-process home.<suffix> host:

host	surface	app
http://status.dmsg/	dmsg	dmsgweb
http://status.skynet/	skynet	skynetweb
http://status.skysocks/	skysocks	skysocks-client

New pkg/proxystatus owns the surface taxonomy, host matcher (Match), the in-process HTTP responder (ServeConn, same net.Pipe trick as serveHomeInProcess), the read-only Snapshot/Provider contract, and the HTML renderer. Both resolving proxies' Dial callbacks check Match(host) before suffix resolution / upstream forwarding, so any of the three hosts is reachable through either proxy.

The visor implements proxystatus.Provider (pkg/visor/embedded_proxystatus.go) entirely on existing read APIs:

• logging — LogsSince(app) tails the app's log store;
• mux view — RouteGroupMuxInfo(app) gives the same per-leg bandwidth/RTT/retransmit telemetry cli proxy mux plot renders, drawn as a per-leg bandwidth-share table (meta-refreshes to stay live);
• running — procManager.ProcByName(app).

Implemented vs. scaffolded

• status.skysocks — full MVP: logs + live per-leg mux view of the route group where multiplexing actually happens.
• status.dmsg / status.skynet — share the identical page; mux section is empty until their route group is tagged for RouteGroupMuxInfo.
• route/transport events — empty section today; the collection buffer is the scaffolded extension point.

Extension seam: route control

MVP is deliberately read-only. The page renders a disabled "route control" section, and Snapshot/Provider are shaped so control lands additively: add a mutating method to proxystatus.Provider, implement it on the existing visor mux-reshape API (AddMuxRoute/RemoveMuxRoute/SetMuxMode) + dmsg relay selection. No wire reshape, no new proxy plumbing. Interception in skysocks-client for the browser-points-directly-at-:1080 case is a noted future seam.

Scope / testing

Contained to the embedded-web-proxy packages + pkg/skynetca (the permit helper) + a small visor status provider; pkg/router/policy untouched. go build ., go vet, make format clean. New unit tests for pkg/proxystatus (Match/Render/ServeConn), skynetca.Permits, and the interstitial status footer.