feat(services): use stable hash-based service hostnames to relax name limits

User Story

As part of my work on OpenShell service exposure, I received feedback that the current name-length restrictions can be limiting. I need descriptive workspace, sandbox, and service names without having to shorten all three to fit their combined service hostname.

Problem Statement

OpenShell currently enforces a 19-character maximum on each workspace, sandbox, and named service. Service hostnames concatenate these names into a single DNS label:

<workspace>--<sandbox>--<service>.<base-domain>

The unnamed/default service omits the service segment:

<workspace>--<sandbox>.<base-domain>

The shared limit explicitly budgets for the named-service form: 19 + 2 + 19 + 2 + 19 = 61, within the 63-character label budget. These are per-name limits, not a 19-character limit on the complete URL. Workspace and sandbox creation enforce them independently of whether a service is exposed.

Impact / Why This Matters

Users must abbreviate meaningful workspace, sandbox, and service names to satisfy a constraint imposed by URL composition. Even a short service name cannot make room for a longer workspace or sandbox name under the current fixed per-name allocation. This couples object naming to the routing format and reduces readability in CLI output and automation.

Proposed Design

Consider changing the default service hostname to use a deterministic hash-derived prefix while retaining the service name at the end of the label:

<stable-hash>--<service>.<base-domain>

The hash should be derived from stable workspace identity and, likely, sandbox identity. The same workspace/sandbox should produce the same prefix across service queries, gateway restarts, and gateway replicas. Named services on that sandbox should share the prefix and differ by their readable service suffix.

A workspace-only hash remains an alternative, but it must include another way to distinguish different sandboxes exposing the same service name. A workspace-plus-sandbox hash naturally provides that distinction without retaining a long sandbox name in the URL. This proposal means deterministic hashing, not consistent-hashing placement across nodes.

Relax the existing 19-character object-name limits where the new URL format removes their justification, subject to independent backend and resource-name constraints. Document the resulting supported limits, including the remaining budget for the readable service suffix.

Define how incoming hashed hostnames resolve to the correct workspace, sandbox, and service. Hash collisions must never cause traffic to reach a different endpoint. Hashes identify routing targets; they do not grant access.

Suggested UX

Users continue exposing services through the existing OpenShell workflow. Returned service URLs change in shape, for example:

Current:  https://team--devbox--web.services.example.com/
Proposed: https://<stable-hash>--web.services.example.com/

The prefix above is illustrative; its encoding and length remain design decisions. Define an equivalent URL for the unnamed/default service, such as <stable-hash>.<base-domain>.

CLI and SDK responses should continue returning the authoritative URL, so callers do not need to construct it. Document what happens to existing URLs on upgrade and provide a clear compatibility or migration policy for bookmarks and integrations.

Acceptance Criteria

• New service URLs use a documented deterministic hostname format with a readable named-service suffix.
• Supported workspace and sandbox names longer than 19 characters can be created and used for service exposure; independent limits are documented and validated clearly.
• The maximum supported service-name length is derived from and validated against the chosen hostname budget.
• Different sandboxes in one workspace, and equivalent sandbox/service names in different workspaces, resolve to their intended endpoints.
• URL generation remains stable across restarts and replicas for the same identities and configuration.
• Collision handling cannot silently route a request to another endpoint.
• Named and unnamed services work through the existing CLI, SDK, and gateway routing paths.
• Existing service authentication and browser-origin protections remain effective with the new naming scheme.
• Upgrade behavior for existing URLs, deletion/recreation semantics, and any URL changes are documented and tested.
• Tests cover name-length boundaries, deterministic generation, endpoint resolution, and workspace/sandbox separation.

Alternatives Considered

• Keep the current format and 19-character limits: preserves readable, directly parseable URLs but retains the reported restriction.
• Allocate a combined 63-character budget dynamically: permits some longer names but still couples all three names and makes exposure depend on their combined lengths.
• Hash only the workspace: shortens one component but requires retaining or otherwise representing sandbox identity to avoid ambiguity.
• Use a fully opaque endpoint identifier: decouples URL length from names but loses the requested readable service suffix and needs a defined stability contract.
• Use multiple DNS labels: preserves names but changes wildcard DNS and certificate requirements.

Middleware, interceptors, and credential providers do not address this constraint: it is enforced in core object validation and gateway hostname generation/parsing.

Open Design Questions

• Should the hash use workspace/sandbox names or persistent IDs? Names can preserve URLs across recreation; IDs distinguish replacement resources. Specify the intended lifecycle behavior.
• What hash length, encoding, and collision behavior provide the required uniqueness within the DNS budget?
• Should old URLs remain accepted temporarily, and how should existing browser-origin checks handle aliases?
• What larger name limits are supported by each compute backend and derived resource name?

Agent Investigation

Verified by source inspection at commit 10241ab47b3b83cf5c9e9c854951c663a3af2c99; no runtime tests were executed for this draft.

• crates/openshell-server/src/grpc/mod.rs:145: MAX_ROUTABLE_NAME_LEN = 19, with an explicit comment explaining the three-segment DNS-label budget.
• crates/openshell-server/src/grpc/workspace.rs:78: workspace validation enforces that constant.
• crates/openshell-server/src/grpc/validation.rs:241: sandbox validation enforces that constant. Existing tests accept the boundary and reject the next length.
• crates/openshell-server/src/grpc/service.rs:26: service-name validation uses the same constant through MAX_SERVICE_NAME_LEN.
• crates/openshell-server/src/grpc/sandbox.rs:282: generated sandbox names are also truncated to the routable-name limit.
• crates/openshell-server/src/service_routing.rs:186: endpoint_host generates the current concatenated hostname; parse_host decodes it directly into workspace/sandbox/service. A hash-based format therefore requires a resolution design as well as URL formatting changes.
• crates/openshell-server/src/service_routing.rs:235: service-request classification relies on hostname parsing. Cross-origin rejection logging also parses these hostnames at line 855; review both paths with the routing change.