Upgrade EdgeZero to v0.0.7 and complete staging runtime integration

[aram356]

Summary

Upgrades all six EdgeZero workspace dependencies from v0.0.4 to v0.0.7 and completes the Trusted Server integration for the full release delta.

• Pin edgezero-adapter-{axum,cloudflare,fastly,spin}, edgezero-cli, and edgezero-core to tag = "v0.0.7" (5c9886e5). The lockfile update is scoped to the EdgeZero tree; the required non-EdgeZero additions are syn 3 and toml_edit 0.25.
• Declare Trusted Server's trusted_server_config store metadata and add EnvConfig-aware store-name/key selectors while retaining the existing native default helpers.
• Load runtime_env_config(TrustedServerApp::stores()) once in the Fastly entry point and reuse it for the JA4 settings read, physical store open, application construction, and both fallback settings reloads.
• Production therefore reads trusted_server_config from the trusted_server_config physical store, while staged versions can select trusted_server_config_staging through the version-linked edgezero_runtime_env store. Physical store-name overrides remain independent of key selection.
• Migrate TrustedServerAppConfig to the v0.0.7 AppConfigMeta::secret_fields() API.
• Remove the obsolete staging limitation from the docs and document capture-before-deploy rollback guidance.

v0.0.4 to v0.0.7 audit

The upstream functional changes were audited through the v0.0.7 tag:

• App-config metadata/secret-field API changes are adopted. Trusted Server deliberately keeps its existing inline app-config blob model; moving application secrets into platform secret stores remains separate operator-migration work.
• Config-store chunk GC is exposed as ts config gc, including preview/destructive gates, age filtering, --store, and --no-env targeting behavior.
• Fastly staged deploy, healthcheck, rollback, and active-version lifecycle commands are exposed, with staging config push/diff flags and fail-closed deploy passthrough parsing.
• The v0.0.7 runtime selector API is wired into Trusted Server's custom Fastly entry point, closing the prior staging-config gap.
• Rollback documentation no longer implies that the previously active production version can be reconstructed after deployment.
• Dependency/tooling-only upstream changes were covered by the complete Rust, adapter, JavaScript, documentation, and integration matrix below.

CLI coverage

Every downstream operational EdgeZero handler is exposed by ts:

ts surface	EdgeZero handler
active-version	run_active_version
auth	run_auth
build	run_build
config diff	run_config_diff_typed::<TrustedServerAppConfig>
config gc	run_config_gc
config push	run_config_push_typed::<TrustedServerAppConfig>
config validate	run_config_validate_typed::<TrustedServerAppConfig>
deploy	run_deploy
healthcheck	run_healthcheck
provision	run_provision
rollback	run_rollback
serve	run_serve

Trusted Server's own audit, config init, prebid, and dev commands remain intact. ts new is intentionally not included. EdgeZero's feature-gated contributor-only demo server is not a downstream CLI operation and is not enabled.

Argument coverage includes the remaining proof gaps from the v0.0.4→v0.0.7 audit: healthcheck --path, config gc --store, and config gc --no-env, in addition to retry/staging/rollback/destructive-GC behavior.

Verification

Self-review and an independent code review found no remaining critical, important, or minor issues. The final branch passes:

• Locked dependency metadata, narrow lockfile audit, cargo fmt --all -- --check, and git diff --check.
• Clippy for Fastly, Axum, Cloudflare native/wasm, Spin native/wasm, CLI, codegen, and the integration manifest.
• Rust tests for Fastly/core, Axum, Cloudflare, Spin, CLI, cross-adapter parity, codegen, and integration crates. The final cargo test-fastly run passed 166 adapter tests, 2,257 core tests (6 expected ignores), 2 JS bridge tests, 21 OpenRTB tests, and 3 doctests (4 expected ignores).
• Adapter build/check gates for Fastly release wasm, Axum, Cloudflare native/wasm, and Spin native/release wasm, plus benchmark smoke coverage.
• JavaScript build, 893 Vitest tests, type checking, lint, and formatting; documentation lint, formatting, and build.
• Template-cache local harnesses: ESI 21/21 and inline 8/8. The harness's auction/provider budgets were raised above its deliberate three-second bid delay to remove an invalid boundary race exposed by this verification run.
• All GitHub checks on the final commit, including Rust/JS/Actions CodeQL, formatting, all adapter/CLI/parity tests, and core/browser/Fastly-EC integration suites.

Explicit exclusions

• No ts new command.
• No deploy-action workflow adoption or other .github/workflows changes.
• No new pull request; this continues PR Upgrade EdgeZero to v0.0.7 and complete staging runtime integration #940.

Closes #939
Closes #1082

[aram356]

Status update — P0/P1 tracking

Head: `96dd1f72` (main merged in twice since the original commit; edgezero dep unchanged, no conflicts).

P0.2 — CI + output-line contract

• Local verification at head is green: fmt, clippy (fastly), core+fastly tests (1648+99), vitest (411). The earlier red checks were a systemic/environmental run on `96dd1f72` (every job failed, incl. JS/fmt that pass locally) — fresh reruns of all four workflows are in progress.
• Machine-readable output lines the deployer parses are verified end-to-end. All three are emitted by edgezero-cli at `log::info!` (Info→stdout), and `ts`'s `main.rs` calls `edgezero_cli::init_cli_logger()`, so they reach stdout rather than being swallowed:

  Line	Source (edgezero @ 145f1699)
  `version=`	`edgezero-cli/src/lib.rs:253`
  `pushed-key=`	`edgezero-cli/src/config.rs:386`
  `rolled-back-to=`	`edgezero-adapter-fastly/src/cli.rs:2807`

• Dispatcher/arg-parse tests for `active-version`, `healthcheck`, `rollback` are in `crates/trusted-server-cli/src/run.rs`.

P1.3 — edgezero library ↔ action lockstep (recorded pair)

The `ts` CLI is built from this repo's `Cargo.toml` (edgezero library rev), and the deployer separately pins `stackpop/edgezero/.github/actions/deploy-fastly@` (edgezero action ref). These MUST be the same edgezero commit so library and action can't diverge.

• Current pair: both = `stackpop/edgezero@145f1699` (branch `feature/edgezero-deploy-actions`).
• On merge: when edgezero Remove immutable cache headers from integrations #316 lands and is tagged, move BOTH the six `Cargo.toml` deps and the deployer's `deploy-fastly@` to that same tag/SHA in lockstep.

P0.1 — re-pin off the moving branch (blocker, still open)

edgezero #316 is not yet merged and no new tag exists. Cannot re-pin until it lands; PR stays draft until then.

[prk-Jr]

Summary

Tight, well-tested upgrade: six edgezero deps repointed at the deploy-actions branch, SECRET_FIELDS migrated to secret_fields(), and the new active-version / healthcheck / rollback / config gc subcommands wired through with argument-parsing coverage for each. Dispatch is a clean passthrough and every new command has a doc comment. Two things block: the dependency reference is mutable while upstream #316 is still open, and the operator docs weren't updated for the new (partly destructive) surface.

Blocking

🔧 wrench

• Mutable branch = dep on an unmerged upstream PR (Cargo.toml:57-62): upstream stackpop/edgezero#316 is confirmed open / merged: false, but this PR is isDraft: false and MERGEABLE. See the inline comment for the rev pin suggestion.

• docs/guide/cli.md not updated for the new CLI surface: four subcommands ship undocumented — active-version, healthcheck, rollback, and config gc. config gc is the one that matters most: with --yes and --older-than it destructively sweeps config-store entries, and the only place its semantics are written down right now is a one-line clap doc string and three parse tests. The "Lifecycle commands" block (docs/guide/cli.md:79-90) and "Configuration commands" block (:43-77) both enumerate the available commands, so they read as complete and are now silently wrong.

  The same file also carries a version claim that this PR invalidates (docs/guide/cli.md:67-70):

  EdgeZero v0.0.4 only overrides leaves already present in the TOML; add newly introduced fields to existing configs before relying on their overrides.

  The dependency is no longer v0.0.4. Either confirm the behavior still holds on the new tree and drop the version qualifier, or update it to whatever gets pinned at merge time.

Non-blocking

🤔 thinking

• Unrelated dependency downgrades in the lock refresh (Cargo.lock): windows-sys 0.61.2 → 0.48.0 and itertools 0.13.0 → 0.10.5. Details and a scoped cargo update inline.

🌱 seedling

• ts --version can't identify the embedded edgezero (crates/trusted-server-cli/src/run.rs:16): follow-up, not this PR.

📝 note

• secret_fields() port (crates/trusted-server-core/src/config.rs:115): mechanical and correct; the empty-set caveat above it is unchanged.

👍 praise

• deploy_rejects_renamed_stage_flag_before_separator (crates/trusted-server-cli/src/run.rs:306): catches a silent staging→production routing hazard created by the upstream flag rename plus last = true passthrough.

CI Status

All 19 checks green on fe5767e — reported from GitHub, not re-run locally:

• fmt: PASS
• clippy (fastly / axum / cloudflare native + wasm / spin native + wasm): PASS
• rust tests (core, axum, cloudflare, spin, ts CLI, cross-adapter parity): PASS
• integration + browser integration + Fastly EC lifecycle: PASS
• js tests (vitest) / format-typescript / format-docs: PASS
• CodeQL (actions, javascript-typescript, rust): PASS

[aram356]

Need to merge stackpop/edgezero#351 and stackpop/edgezero#352

[jwrosewell]

Approved, and no objection to the upgrade itself. One sequencing note before it lands.

This PR changes config.rs, trusted-server.example.toml, configuration.md and cli.md, which the provider stack in #1043–#1047 and #1094 also touches. To avoid a conflict that one side then has to unpick, could #940 merge behind that stack rather than ahead of it?

If the stack can't be merged quickly and #940 needs to go first, the alternative we suggested to Rowena, Jason and Shailley is a release branch model: keep the current live branch and the next release branch in sync, so both sets of changes land without either blocking the other.

Either order works for us. Flagging it now so whoever merges first knows the other is coming.

[aram356]

Approved, and no objection to the upgrade itself. One sequencing note before it lands.

This PR changes config.rs, trusted-server.example.toml, configuration.md and cli.md, which the provider stack in #1043–#1047 and #1094 also touches. To avoid a conflict that one side then has to unpick, could #940 merge behind that stack rather than ahead of it?

If the stack can't be merged quickly and #940 needs to go first, the alternative we suggested to Rowena, Jason and Shailley is a release branch model: keep the current live branch and the next release branch in sync, so both sets of changes land without either blocking the other.

Either order works for us. Flagging it now so whoever merges first knows the other is coming.

This PR Iis currently blocking deployment workflows for active prospects, so holding it behind the provider stack would have a direct customer impact.
The #1043–#1047/#1094 stack can then rebase onto #940 and resolve the overlapping config and documentation changes against that baseline. I don’t think we need the added release-branch overhead solely for merge sequencing.