fix(cli): serve remote access on a random unguessable subdomain

[thdxr]

Issue for this PR

Closes #

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Remote access served the service on a fixed subdomain of the device's OpenTunnel tunnel (opencode, opencode-<channel>). Tunnel hostnames are published in certificate transparency logs, so the remote address was guessable and anyone could reach the service's sign-in.

The route is now 16 random hex characters (64 bits from crypto.randomBytes), for example https://3f9c2a7be41d08c6.<tunnel-id>.opentunnel.xyz. The tunnel certificate covers subdomains with a wildcard, so the route never appears in certificate logs, and OpenTunnel drops connections for routes nobody claims. Server authentication is unchanged and still required on every request.

• The service config stores remote access as an object: "remote": { "route": "…" } when on, absent when off. The route is generated once, so the URL survives restarts; turning remote off forgets it, so turning it on again issues a new address.
• Configs written by earlier builds ("remote": true|false) still decode, keeping the rest of the config. A service started with true generates its route on first start.
• opencode service get hides the route, like the password.

How did you verify your code works?

• Tests for route generation (valid OpenTunnel route name, stable once created, hidden, forgotten when remote is turned off) and for decoding legacy boolean configs without losing other settings.
• Decoded a real service.json containing "remote": true: all other keys, including the password, were kept.
• Live against a real default tunnel: the random route served the running service (401 without credentials); another random route got no response.
• bun run check passes.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊