Expose a public runtime-env EnvConfig API for custom Fastly entry points #349

Problem

edgezero-adapter-fastly resolves EDGEZERO__* runtime overrides from the version-linked edgezero_runtime_env Fastly Config Store in env_config_from_runtime_dictionary (src/lib.rs:177 at v0.0.6). That function is private and only reachable through run_app / the dispatch path.

A downstream app with a custom Fastly entry point (Trusted Server bypasses run_app and builds its app directly) cannot resolve those overrides without duplicating the store name, the key spellings, and the key-derivation rules — internals that can drift.

Consequence downstream

The Fastly staging lifecycle shipped in #316 relinks edgezero_runtime_env for a staged version and redirects EDGEZERO__STORES__CONFIG__<ID>__KEY to <id>_staging. Trusted Server's entry point resolves its config selectors via EnvConfig::from_env() (empty on Compute), so a staged version silently loads the production config blob — a staging healthcheck exercises the new binary against production config and can false-pass. Reported in IABTechLab/trusted-server#940 review.

Proposal

Export the runtime-env loader as public API from edgezero-adapter-fastly, e.g.

pub fn runtime_env_config(stores: StoresMetadata) -> EnvConfig

or a narrower helper that takes the logical store ids to resolve. Downstream custom entry points then resolve staged selectors identically to run_app, with one source of truth for the store name and key list.