Allow opt-in privileged API access for explicitly trusted hosts (remote settings/credentials management)

[Arekejoker]

Scenario

Running dsh web on a headless home server and managing it remotely over a private tailnet (Tailscale HTTPS serve → dsh web --trusted-host <host>.ts.net).

Chat/session APIs work fine from the trusted host, but the settings page is unusable remotely: every privileged method returns 403 Forbidden. First-time setup (adding model providers/keys, choosing a workspace directory) therefore requires physical console access or an SSH tunnel, which defeats the purpose of --trusted-host for home-server deployments.

Current behavior

In @deepseek-ai/dsh-client-connection, PRIVILEGED_METHODS (settings.describe/update/replace/mutate/openDocument, credentials.describe/set/unset, llm.discoverModels, agentPreset.read/copy/openDocument/remove, host.pickDirectory/openPath) are checked with an empty trust list:

isTrustedApiRequest(request, [])   // loopback only, trustedHosts not passed

So --trusted-host grants access to regular APIs but never to privileged ones. I understand this is a deliberate defense (e.g. DNS rebinding), and the default should stay loopback-only.

Proposal

An opt-in way to extend trust to privileged methods for explicitly configured hosts, e.g.:

# settings.yaml (or CLI equivalent)
trustedHosts:
  - host: myserver.ts.net
    privileged: true        # opt-in, default false

or a dedicated flag such as --trusted-host-privileged <host>.

Requirements I'd expect (and that my local test kept intact):

• Default remains loopback-only; nothing changes unless the user opts in per host.
• The existing Origin check (Origin host must equal Host) still applies, so cross-site requests stay rejected.
• Only hosts the user explicitly names get privileged access — no wildcards.

Verification

I locally patched the privileged check to pass trustedHosts instead of [] and verified:

• Trusted host (correct Host + matching Origin) → 200 on settings.describe
• Spoofed Host header from an untrusted origin → 403
• Cross-site Origin → 403

So the fence logic itself already supports this; it's only the hardcoded empty list that blocks it. Happy to provide more details or test a PR.