feat(services): publish authoritative application origins independently of API transport #4953

Parent: #4670 (authoritative URLs and installation status). Dependency: #4941.

User Story

I use OpenShell to expose sandbox services through independently operated ingress. I need CLI and SDK responses to return the configured public application origin even when my gateway API uses another host or a local port-forward.

Problem Statement

Application URLs derived from the API endpoint can select the wrong ingress host or port. Public URL publication needs a reviewable implementation separate from installation status.

Impact / Why This Matters

Callers otherwise reconstruct addresses manually and may send application requests to the control plane rather than the configured application ingress.

Proposed Design

Publish an explicitly configured HTTPS application origin and retain an explicit gateway-mediated URL. Preserve the public port across CLI and SDK access and durable mutation replay. Keep ingress authentication boundaries documented. Installation status remains in #4670.

Suggested UX

[openshell.supervisor.app_listener]
enabled = true
port = 9443
domain = "services.example.com"
public_url = "https://services.example.com:10443"

Responses distinguish the preferred URL, application URL, and gateway URL. An API port-forward must not rewrite the public application port.

Acceptance Criteria

• Named and unnamed service create/expose/list/get responses publish the configured public origin.
• CLI and supported SDKs preserve the public origin independently of API transport.
• Durable replay preserves resource identity while recomputing current origins.
• Invalid origins and listener-domain mismatches fail clearly.
• Gateway access remains available; direct listener authentication belongs to the ingress provider.
• Tests and configuration documentation cover nondefault public ports and API port-forwarding.

Alternatives Considered

Manual reconstruction and client-specific rewriting duplicate routing policy. Middleware, interceptors, and providers do not supply an authoritative origin across API and SDK responses. Existing ingress integrations remain supported.