Bind Fastly stores selected by each deployment environment

[aram356]

Problem

PR #344 made Fastly store selection depend on a shared edgezero_runtime_env Config Store and descriptor keys containing a Fastly service ID and version. That duplicated Fastly's version-scoped resource binding, introduced mutable shared state, and made application runtime code participate in deployment-target selection.

An application release must remain byte-identical across publishers, production, and staging. The deploy workflow chooses the publication target, and the selected deployment environment may choose the same or different physical Config, KV, and Secret Stores without changing application behavior or release bytes.

Required contract

• Applications declare stable logical store IDs in edgezero.toml.
• Application runtime code always opens those logical aliases and does not decide whether a deployment is staging.
• Fastly Config Stores always use <logical-id> as the entry key.
• The selected deployment environment chooses physical stores through:
  • EDGEZERO__STORES__CONFIG__<ID>__NAME
  • EDGEZERO__STORES__KV__<ID>__NAME
  • EDGEZERO__STORES__SECRETS__<ID>__NAME
• Managed Fastly deployment binds each selected physical resource to the unpublished version under its logical alias.
• Production and staging may select the same physical store or different physical stores.
• Secret Stores remain optional unless declared by the application manifest.
• The deployment target, service, publisher environment, and store selections are deployment inputs and are not baked into the application binary.

For example, production may select config-prod and staging may select config-stage. Both deployed versions expose the alias and key app_config.

Acceptance criteria

• Remove edgezero_runtime_env, runtime descriptors, service/version EDGEZERO__* keys, staging selector stores, and EDGEZERO_FASTLY_BUILD_SETTINGS introduced by Support optional typed secret paths and Fastly store mappings #344.
• Do not migrate, read, or fall back to Support optional typed secret paths and Fastly store mappings #344 descriptor entries.
• Do not pass the publication target into runtime store configuration.
• Reject present blank or invalid __NAME and __KEY values before config push or deployment performs provider I/O.
• Reject a Fastly __KEY or CLI --key that differs from the logical ID.
• Keep generic CLI/config code adapter-independent; Fastly owns resource-link and fixed-key policy.
• Reconcile declared links by resource kind and logical ID, replace changed declared links, and preserve undeclared inherited links.
• Use the supported Fastly CLI service resource-link ... and service version ... hierarchy. Keep the 15.1.0 pin for this change rather than coupling it to a major-version upgrade.
• Accept the live Fastly resource types config, kv-store, and secret-store.
• Use exact Fastly environment name and active-version records for staging state and rollback; accept Fastly's distinct shadow staging service ID.
• Reject a lone retry draft beside an existing staged source.
• Avoid the Fastly version-diff endpoint for Compute deployment preflight. Snapshot versioned domains, backends, health checks, logging endpoints, and settings instead. Canonicalize JSON object-key order recursively before comparing snapshots. Use the live logging REST endpoint kinds, including pubsub, logentries, and s3, and never request googlepubsub.
• Verify source and draft configuration, exact links, package identity, and publication state at the appropriate mutation barriers.
• Keep the application CLI, complete edgezero.toml, and package bytes identical across publishers and targets.
• Package and digest only the selected adapter manifest at its declared relative path.
• Keep whole-project validation in config validate; targeted config push/diff --adapter <name> validates only the selected adapter.
• Keep immutable-release verification and application CLI invocation provider-neutral. Fastly wrappers supply Fastly-specific policy.
• Refactor run-app-cli.sh in place and colocate Fastly lifecycle fixtures in deploy-fastly/tests.
• Verify the complete lifecycle command/flag protocol and selected source revision before provider mutation.
• Rename the build action archive to app-cli.tar without changing its configurable artifact name, application binary/package name, or immutable member cli/app-cli.tar.
• Retain uploaded application CLI and release artifacts for 14 days.
• Provide a provider-neutral setup-rust-build-cache action whose required app-name isolates dependency and optional Cargo target caches for each release producer without changing its build, package, adapter, or deployment commands.
• Keep action and CI tooling free of Python and pip commands.
• Preserve unregistered store-free custom commands and optional Secret Stores.
• Document custom entrypoint migration, cross-repository immutable release retrieval, and mutable-config recovery.
• Keep the real Fastly hostname constant across targets; use staging.<domain> only as the GitHub Environment identifier.
• Cover selectors, resource links, release packaging, publication barriers, lifecycle compatibility, rollback states, action contracts, and documentation with tests.

Every deployment and other version mutator for one Fastly service must share caller-side serialization because Fastly does not expose a publication compare-and-swap token.

Downstream build-action consumers must update to app-cli.tar.

Implementation: #381