Finish hosted managed preview public paths

Summary

Hosted/no-subdomain managed-command dev previews still launch with local/trusted service-scoped public paths such as /preview/services/<service_id>/, while user-facing hosted links should open capability URLs such as /preview/p/<token>/.

Hot-reload frameworks may emit asset, websocket, or HMR URLs from CAR_PREVIEW_BASE_PATH / CAR_PREVIEW_PUBLIC_URL. If those env vars point at /preview/services/<service_id>/, unauthenticated hosted browsers can request authenticated service routes and receive 401, even though the opened preview capability URL itself works.

This was the residual gap from PR #2016 after hosted browser bearer bootstrap, bearer-aware SSE, and base-path preview hardening landed.

Acceptance criteria

• Hosted/no-subdomain managed previews receive env/config values that match the path a browser should use for assets and HMR.
• The design avoids putting long-lived secrets into managed process environments unless there is an explicit risk decision and mitigation.
• Local/trusted mode keeps /preview/services/<service_id>/ compatibility.
• Hosted mode either issues an appropriate launch-time capability path, uses a stable non-secret public alias, or clearly disables/marks unsupported dev-server patterns with operator-visible messaging.
• UI/CLI/docs distinguish local trusted service routes from hosted public capability routes.

Validation

• Add focused tests for managed-command environment construction in local/trusted and hosted/no-subdomain modes.
• Add a route or integration regression showing a hosted managed preview asset path uses the same public prefix as the opened link.
• Run .venv/bin/python -m pytest tests/core/test_preview_services_supervisor.py tests/surfaces/web/test_preview_services_routes.py -q after implementation.