Portals: reach a dev server running on any machine through the relay

[karngyan]

Why

An agent on the VPS starts vite on port 5173 and you are on your phone. Today flue shows you the log lines and nothing else. Amp ships this as Portals (authenticated URLs to dev servers inside their cloud orbs, with an element-comment review widget) and Conductor Cloud ships port forwarding, but both are hosted products. flue's version runs through a relay you own, end to end encrypted, authenticated by the pairing you already did.

Rough scope

• A "share port" action on a session or machine: daemon proxies HTTP to a local port and carries it over the existing encrypted channel, the way terminal frames already travel.
• Browser side, requests for the portal are routed through the service worker into the channel, so the page loads from an authenticated context without the relay ever seeing plaintext.
• Websockets should pass through, otherwise HMR dies and the feature misses its main use.
• UI: list of open portals per machine, open and revoke. Auto close when the session ends, with an option to keep.

Hard parts, named up front

• HTTP over the noise channel via service worker routing is real engineering, not glue.
• Origin isolation: a proxied app must not share cookies or storage with the flue UI. Path-based routing makes that hard, a separate origin per portal is cleaner but interacts with the relay's single origin.
• Free-plan Worker cost: a chatty dev server is exactly the traffic shape docs/FOLLOW-UPS.md item 13 worries about. The per-session rate cap work is related.

Biggest lift in the daily-driver group, and probably the single most differentiating feature on this list.