test: nothing models the browse-origin deployment (Tier D — subdomain routing, TLS, cookie isolation)

[0pcom]

The browse-origin path is live on the hosted deployment and almost nothing in CI models it.

Where it lives

haltingstate.net is not a default baked into any binary. It is a deployment: Caddy vhosts for dmsgd. / ar. / rf. / tpd. / sd. / conf. (documented in docs/deployment/DEPLOYMENT_SYSTEMD.md:797-819), with conf.haltingstate.net serving the service-conf JSON that visors fetch via config gen -a conf.haltingstate.net. The browse origin itself is config — BrowseOrigin.Suffix (pkg/visor/visorconfig/v1.go:386), default .mesh.localhost, set to .haltingstate.net for the hosted deploy, surfaced as hv serve --browse-suffix.

What is covered now

pkg/visor/meshproxy.go (544 lines) and pkg/visor/wasmserve.go (731 lines) had no test file at all until #3925, which adds unit tests for the pure parts: normalizeMeshSuffix, hostWithoutPort, peelNetLabel, rewriteMeshLocation, isMeshBrowseHost and wasmPasswordGate.

That covers the parsing and the redirect-containment decisions. It does not cover the parts that only exist when something is actually served.

What is still unmodelled

• Subdomain routing end to end — a request to <site>.mesh.localhost reaching the right destination over dmsg/skynet, including the .skynet / .dmsg net-label variants that peelNetLabel splits off
• Port mode — meshPortManager.originFor, the /open?host=… → 302 portal, per-site port assignment, and the LRU eviction in evictLocked/touchLocked
• TLS — BrowseOriginConfig.TLSCert/TLSKey. The comment says these exist so local runs get "real secure-context, real-domain cookie isolation" parity with the hosted origin. Nothing verifies that parity.
• Cookie isolation between browse frames — the actual security property the per-site origin exists to provide
• Redirect containment in a real browser — rewriteMeshLocation is unit-tested now, but not that a browser genuinely stays inside the frame origin

Proposal

Run the browse origin locally at .mesh.localhost with an mkcert cert and drive it with a browser, reusing the Tier C rig from #3927:

1. serve two distinct sites through the browse origin
2. assert each resolves to its own origin and its own port in port mode
3. assert a cookie set by one site is not visible to the other
4. assert a redirect to the upstream vhost stays inside the frame origin, and one to a genuinely different host does not
5. assert the /open?host= portal path 302s correctly

This is the piece that would actually catch a regression in what is deployed, rather than in what compiles.

Related: #3925 (unit tests), #3927 (browser rig).