Upstream request: let a declared trusted host satisfy the client's settings trust

[ArndRosemeier]

#Upstream request: let a declared trusted host satisfy the client's settings trust

Target: deepseek-ai/deepseek-harness (observed on dsh 0.1.5-rc.2)

Summary

When the dsh web UI is served through a reverse proxy or tunnel — for example behind Cloudflare
Access — the Settings pages do not render for the remote browser:

Loading the provider directory failed: settings are unavailable in this browser

Coding, sessions, file views and the /api surface all work normally. Only the host-privileged
settings surfaces are withheld.

Why it happens

dsh-client-connection classifies the page:

isLoopback: transport?.ownsHost === true
  || pageLocation === void 0
  || isLoopbackHostname(pageLocation.hostname)     // localhost, [::1], 127/8

and the settings shell derives persistence from that state when it applies:

const persistence = ctx.remote.$host.isLoopback ? "host" : "memory";
const mirror = new SettingsDescribeMirror(ctx, persistence);

With a remote page the mirror is process-local and has no view, so every settings page — models,
general, plugins — reports unavailable. describeFace.ensure() returning no view is what the
modal surfaces.

dsh web --trusted-host (and web-app's trustedHosts) declares authorities for the /api
Host fence, which is a separate mechanism: the client bundle never reads trustedHosts at all.
connection's own config exposes only timing keys, so there is no configuration path to the
settings surface in a proxy-served deployment.

Proposal — any of these would be sufficient

1. Treat an authority declared in trustedHosts as satisfying the client's settings trust, either
   by folding it into isLoopback or by introducing a separate isTrustedHost that the settings
   shell honours.
2. A dedicated opt-in, e.g. dsh web --allow-remote-settings or connection.settingsTrust: [...].
3. Let the settings shell fall back to the host-backed mirror when the page is served over HTTPS
   from a declared trusted authority.

Context for the argument

• The fence's own source comment states it "is not an auth layer". In proxy-served deployments
  authentication belongs to the proxy (Cloudflare Access, oauth2-proxy, Tailscale, …), so the
  loopback check blocks legitimate use rather than adding protection.
• Anyone able to reach the page has already authenticated and can drive the agent, which holds
  host filesystem access — so the incremental exposure from rendering the settings is small.
• The alternative workaround is to reach the UI over a loopback origin (an SSH port-forward, or a
  browser running on the host). That works, but it is an awkward requirement for a UI whose whole
  point is remote access.