feat: read tunnel endpoint from /etc/glueops/tunnel_endpoint

[venkatamutyala]

What

Makes the sish tunnel endpoint configurable per VM instead of hardcoded. dev() now reads /etc/glueops/tunnel_endpoint (written by cloud-init on newer platform deployments) and falls back to the legacy tunnels.glueopshosted.com when the file is absent or empty:

TUNNEL_ENDPOINT="tunnels.glueopshosted.com"
if [ -s /etc/glueops/tunnel_endpoint ]; then
    _regional_endpoint="$(head -n1 /etc/glueops/tunnel_endpoint | tr -d '[:space:]')"
    [ -n "$_regional_endpoint" ] && TUNNEL_ENDPOINT="$_regional_endpoint"
fi

TUNNEL_BIND="cde"
[ "$TUNNEL_ENDPOINT" != "tunnels.glueopshosted.com" ] && TUNNEL_BIND="$HOSTNAME"
...
autossh ... -R "$TUNNEL_BIND":80:localhost:8000 "$TUNNEL_ENDPOINT"

The bind name follows the same endpoint-value rule: on the legacy central endpoint the VM binds cde (that sish runs --append-user-to-subdomain, producing cde-<hostname>.tunnels...), while on any regional endpoint it binds its bare $HOSTNAME, producing <hostname>.<region>.tunnels.cde.glueopshosted.com — no redundant cde- prefix. The slackbot's cdeAccessUrl() derives URLs from the identical rule, so tunnel and URL can never disagree.

This is part of the regional tunnel endpoints rollout: each datacenter gets its own sish instance (<region>.tunnels.cde.glueopshosted.com, run WITHOUT --append-user-to-subdomain and with --bind-random-subdomains=false) so codespaces connect to the closest tunnel instead of the single central one. Companion PRs: GlueOps/provisioner (tunnel_endpoint region config field) and GlueOps/slackbot-developer-workspaces (endpoint resolution, VM tagging, access URLs, cloud-init file write).

Backward compatibility

• Existing VMs run the old baked image and are untouched.
• A VM built from this image with no /etc/glueops/tunnel_endpoint file behaves exactly as before (central tunnel).
• The new slackbot writes the file for every CDE VM; the REGIONAL_TUNNEL_MIN_IMAGE_TAG gate controls only whether its value can be regional. Images below the gate get the legacy central value — which the old baked dev() ignores (hardcoded central) and the new dev() resolves to identical behavior — so there is no deploy-order hazard in either direction.

How to upgrade

1. Merge this PR and let release-please cut a release. Note the release tag (e.g. v0.155.0).
2. That tag is the value for REGIONAL_TUNNEL_MIN_IMAGE_TAG in the slackbot's environment — the slackbot only assigns regional endpoints to VMs whose selected image is at/above it. Images older than this release bake a dev() that ignores the file, so the gate keeps their tunnels and access URLs consistent (legacy central).
3. Continue with the rollout runbook in the slackbot PR.

🤖 Generated with Claude Code