Staged deploys load production config: resolve config selectors from edgezero_runtime_env

[aram356]

Problem

Found in #940 review: the Fastly staging lifecycle relinks the version-linked edgezero_runtime_env Config Store and redirects EDGEZERO__STORES__CONFIG__TRUSTED_SERVER_CONFIG__KEY to trusted_server_config_staging. Trusted Server's Fastly entry point bypasses edgezero_adapter_fastly::run_app and resolves its config selectors via EnvConfig::from_env() (crates/trusted-server-core/src/settings_data.rs:33-41), which is empty on Compute.

A staged version therefore silently loads the production config blob: ts config push --staging writes a key nothing reads, and ts healthcheck --staging exercises the new binary against production config, which can false-pass an incompatible staged code/config pairing. Documented as a known limitation in docs/guide/cli.md.

Fix

Blocked on stackpop/edgezero#349, which exposes edgezero's runtime-env loader as public API (the store name, key spellings, and derivation rules are edgezero internals; replicating them here would drift).

Once it lands:

1. Build the EnvConfig from the exposed API in the Fastly adapter before constructing TrustedServerApp.
2. Resolve both the physical config-store name and the blob key through it (parameterize settings_data's selector helpers on EnvConfig).
3. Add an adapter test proving staging selects trusted_server_config_staging while production selects trusted_server_config.
4. Remove the known-limitation callout from docs/guide/cli.md.

[aram356]

The upstream API is now in review: stackpop/edgezero#351 exposes runtime_env_config for custom Fastly entry points. Once it merges and ships in a tagged release, the wiring here unblocks.