fix(sdk): stop injecting ECLOUD_PLATFORM_HOST into publicEnv (#151)

## Summary

Companion to ecloud-platform
[#154](Layr-Labs/ecloud-platform#154), which
removes the bulk \`spec.Env\` → \`tee-env-*\` propagation in favor of
the platform setting \`tee-env-ECLOUD_PLATFORM_HOST\` directly from
\`cfg.DeriveAppHostname(appAddress)\`. With that landing, the CLI's
client-side injection of the same value into \`publicEnv\` becomes
redundant *and* harmful: it puts a platform-derived value into the
user's on-chain release blob, where it shows up in \`ecloud compute app
info\`, the verify dashboard, and any consumer that reads
\`Release.publicEnv\`. Worse, releases cut against an environment whose
\`AppBaseDomain\` later changes carry a stale hostname forever.

## Change

```diff
-  // 4a. Inject the platform-routed hostname as a public env var so
-  // the VM entrypoint's setup_tls knows which hostname to obtain a
-  // cert for. Platform routing expects every app to answer on
-  // <addr>.<platformEnv>.<appBaseDomain>, so this replaces the
-  // compute-tee model where the user supplied DOMAIN manually. The
-  // user's DOMAIN env var (if any) is carried separately in the env
-  // file and is additive: setup_tls issues a cert for both.
-  const platformHost = derivePlatformHost(environmentConfig, options.appId);
-  if (platformHost !== "") {
-    publicEnv["ECLOUD_PLATFORM_HOST"] = platformHost;
-    logger.info(`Platform hostname: ${platformHost}`);
-  }
+  // ECLOUD_PLATFORM_HOST is intentionally NOT injected into publicEnv.
+  // The platform sets it directly as tee-env-* metadata at VM-create
+  // time (see ecloud-platform pkg/services/infraService/providers/gcp/
+  // compute.go). Platform-derived values belong in platform metadata.
```

\`derivePlatformHost\` itself stays exported in
\`config/environment.ts\` — external consumers (e.g.
\`scripts/e2e/lib/cli.sh\` in ecloud-platform's e2e harness) use it for
client-side prediction when they need to know the platform-routed
hostname before calling \`/info\`.

## Test plan

- [x] \`pnpm tsc --noEmit\` — clean.
- [x] \`pnpm vitest run\` — 35 pass (no behavior change for any test
that doesn't introspect publicEnv contents).
- [ ] After ecloud-platform #154 merges and a new CLI tag (1.0.0-devep5)
ships, re-run
\`scripts/e2e/scenarios/02_platform_deploy_then_platform_upgrade.sh\`
against sepolia-dev.

## Compatibility

This PR is **safe to land before ecloud-platform #154 is deployed**:
- Old CLIs (\`<= 1.0.0-devep4\`) continue to inject
\`ECLOUD_PLATFORM_HOST\` into publicEnv. The platform reads it from
\`spec.Env\` and propagates as \`tee-env-*\`. Works as before.
- New CLI (this PR) doesn't inject. Platform pre-#154 reads no
\`ECLOUD_PLATFORM_HOST\` from \`spec.Env\`, doesn't emit
\`tee-env-ECLOUD_PLATFORM_HOST\`, VM's setup_tls falls back to its
localhost default and Caddy serves on the user's \`DOMAIN\` only. **No
platform routing until #154 lands** — the user app still gets a cert for
any custom \`DOMAIN\` they set.
- Once #154 ships, both CLIs work: the new CLI relies on platform-set
metadata; the old CLI's injected publicEnv \`ECLOUD_PLATFORM_HOST\` is
harmless because the platform's loop is gone.

## Companion PR

- ecloud-platform
[#154](Layr-Labs/ecloud-platform#154) — drops
the spec.Env → tee-env-* loop and explicitly emits the platform
hostname.

Author: mcclurejt

packages/sdk/src/client/common/release/prepare.ts

@@ -11,7 +11,6 @@ import { getImageDigestAndName } from "../registry/digest";
 import { encryptRSAOAEPAndAES256GCM, getAppProtectedHeaders } from "../encryption/kms"; // getAppProtectedHeaders
 import { getKMSKeysForEnvironment } from "../utils/keys";
 import { REGISTRY_PROPAGATION_WAIT_SECONDS } from "../constants";
-import { derivePlatformHost } from "../config/environment";
 
 import { parseAndValidateEnvFile } from "../env/parser";
 
@@ -151,18 +150,19 @@ export async function prepareRelease(
   publicEnv["EIGEN_MACHINE_TYPE_PUBLIC"] = instanceType;
   logger.info(`Instance type: ${instanceType}`);
 
-  // 4a. Inject the platform-routed hostname as a public env var so
-  // the VM entrypoint's setup_tls knows which hostname to obtain a
-  // cert for. Platform routing expects every app to answer on
-  // <addr>.<platformEnv>.<appBaseDomain>, so this replaces the
-  // compute-tee model where the user supplied DOMAIN manually. The
-  // user's DOMAIN env var (if any) is carried separately in the env
-  // file and is additive: setup_tls issues a cert for both.
-  const platformHost = derivePlatformHost(environmentConfig, options.appId);
-  if (platformHost !== "") {
-    publicEnv["ECLOUD_PLATFORM_HOST"] = platformHost;
-    logger.info(`Platform hostname: ${platformHost}`);
-  }
+  // ECLOUD_PLATFORM_HOST is intentionally NOT injected into publicEnv.
+  // The platform sets it directly as tee-env-* metadata at VM-create
+  // time (see ecloud-platform pkg/services/infraService/providers/gcp/
+  // compute.go) from cfg.DeriveAppHostname(appAddress). Putting it
+  // here too would mean the user's on-chain release blob carries a
+  // value the user never supplied, which has two costs:
+  //   1. The hostname appears in the public env list rendered by
+  //      `ecloud compute app info` and the verify dashboard, where
+  //      it's noise to anyone reading the release.
+  //   2. Releases cut against an environment whose AppBaseDomain
+  //      later changes would carry a stale hostname forever.
+  // Platform-derived values belong in platform metadata, not in the
+  // user's release.
 
   // 5. Encrypt private environment variables
   logger.info("Encrypting environment variables...");