Bind Fastly stores selected by each deployment environment #380

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
• Store-targeting commands normalize recognized selector casing, use parent environment > manifest default > logical ID precedence, and reject invalid present selectors before provider I/O.
• 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, GC, provision, or deployment performs provider I/O.
• Apply adapter-scoped manifest environment defaults consistently to deploy, push, diff, GC, and provision; preserve config gc --no-env.
• 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, preserve undeclared recognized Config/KV/Secret links, and fail closed on unknown resource types.
• Provision Fastly setup only when the physical name equals the logical alias. A distinct physical name requires an existing selected service and must not produce a misleading [setup] block.
• 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 an orphan editable draft beside an existing staged or retired source when its ownership cannot be proven, and reject duplicate global staging records.
• 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.
• Verify source and draft configuration, exact links, package identity, and publication state at the appropriate mutation barriers.
• Keep the application CLI, complete edgezero.toml, package, and selected adapter manifest bytes identical across publishers and targets.
• Package 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, and adapters without managed-release support reject --application-release.
• Copy the outer release archive once, authenticate and inspect that copy before extraction, stream internal member hashing through bounded memory, and validate release.json as a confined regular file before opening it.
• Refactor run-app-cli.sh in place and colocate Fastly lifecycle fixtures in deploy-fastly/tests.
• Preserve store-free manifest-command package passthrough while rejecting package overrides for managed immutable releases.
• 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 and document the recovery implications.
• Provide a provider-neutral setup-rust-build-cache action whose required app-name isolates dependency and optional Cargo target caches. Avoid per-commit full target cache entries and prove cross-job restoration.
• Exercise ambiguous production publication recovery end to end through active-version and immutable-release rollback.
• Keep action and CI tooling free of Python and pip commands.
• Preserve unregistered store-free custom commands and optional Secret Stores.
• Document all removed deploy inputs, custom entrypoint migration, cross-repository immutable release retrieval, edgezero_runtime_env cutover, fixed-key staging config re-push, and mutable-config recovery.
• Keep the real Fastly hostname constant across targets; use staging.<domain> only as the GitHub Environment identifier.
• Keep file-based config push bound to the exact committed config file without rejecting an unrelated authenticated release download in the checkout.
• Preserve the required aggregate cargo test check and install every WASM target used by generated-project tests in CI.
• Cover selectors, resource links, the public release-packaging action, 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