[bug] Settings persistence follows the page hostname, not the server's trusted hosts, so a remote browser keeps nothing and re-sees the welcome notice on every load

[mattafaak]

Summary

Settings persistence follows the page's hostname, not the server's trusted
hosts. Any browser that reaches the UI by a hostname — the normal case behind a
reverse proxy, a VPN name, or a LAN name — is treated as remote and keeps
nothing:

• the welcome notice's acknowledgement is process-local, so "Internal Testing
  Notice" reappears on every page load, forever;
• every setting changed from that browser is memory-only and silently lost.

Where it comes from

dsh-client-connection computes

isLoopback: transport?.ownsHost === true
         || pageLocation === void 0
         || isLoopbackHostname(pageLocation.hostname)

and dsh-client-ui-settings turns that into persistence:

const persistence = ctx.remote.$host.isLoopback ? "host" : "memory";

ownsHost is read in that one place and set nowhere in the install, so the
only way to be "loopback" is for the page's own hostname to be localhost,
[::1] or 127.x.y.z.

dsh-client-ui-settings-models then stores the acknowledgement under the
ui-onboarding namespace, and its own comment describes the consequence
accurately: "a remote browser's memory-mode scope never answers and the
acknowledgement stays process-local here."

Reproduction

1. Publish dsh web under a hostname (reverse proxy, VPN, LAN name).
2. Open it, dismiss the Internal Testing Notice, reload.

The notice is back. On the box where this was diagnosed, ui-onboarding had
never been written despite months of daily use.

Why it looks solvable from the server side

The server already has the trust concept this needs: --trusted-host, enforced
with a 403 on every /api call. It knows which origins are legitimate; the
client just does not ask.

Suggested fix

• Let the server tell the client the origin is trusted, and let persistence
  follow that (a canPersist would be clearer than overloading isLoopback); or
• make ownsHost settable, so a deployment can assert it.

Workaround

Patching isLoopback to true in the served client bundle. It works, but it is
a patch to vendored node_modules that any install restores, so it has to be
re-applied from the unit's ExecStartPre and asserted by a health check — which
is a lot of machinery for a one-line policy decision.