esi pins fastly ^0.12, which blocks the fastly 0.13 upgrade

[aram356]

The esi crate declares fastly = "^0.12". EdgeZero moves to fastly 0.13 (stackpop/edgezero#366), and both land in trusted-server-adapter-fastly, so the graph carries two incompatible copies of the same types:

fastly 0.13.1  <- edgezero-adapter-fastly
fastly 0.12.1  <- esi 0.7.2

crates/trusted-server-adapter-fastly/src/esi_assembly.rs passes fastly::http::Response and Request across that boundary, so it fails to compile:

error[E0308]: mismatched types
   --> crates/trusted-server-adapter-fastly/src/esi_assembly.rs:96:9
error[E0631]: type mismatch in closure arguments
   --> crates/trusted-server-adapter-fastly/src/esi_assembly.rs:124:65

ESI is unconditional in that adapter (not feature-gated), so it cannot be sidestepped.

The fix is one line, upstream

esi needs no source changes. Cloning fastly/esi at v0.7.2 and changing only the manifest range:

-fastly = "^0.12"
+fastly = "^0.13"

cargo check -p esi --target wasm32-wasip1 passes clean. With that patched in locally, the entire trusted-server workspace compiles, including the Fastly adapter.

Status upstream

• fastly/esi main still reads fastly = "^0.12".
• Published esi 0.7.2 declares ^0.12 (confirmed via the crates.io dependency API).
• No open PR addresses it. fastly/esi#60 is the v0.7.1 to v0.7.2 release bump and touches only the workspace version and lockfile.

Options

1. Open a one-line PR against fastly/esi and wait for a release.
2. Carry the fix on the existing stackpop/esi fork and reference it from [patch.crates-io] until upstream releases. Note the fork's main is behind upstream (missing v0.7.1 and v0.7.2), so it should branch from upstream v0.7.2.

Surfaced by #1124 / PR #1123, which now carries a temporary [patch.crates-io] pointing at the fork branch. This issue stays open until the range bump is released upstream and that patch can be dropped.

[aram356]

Verified end to end with the one-line fix applied locally, on Rust 1.98.1 and Viceroy 0.21.0.

Cloned fastly/esi at v0.7.2, changed only the manifest range:

-fastly = "^0.12"
+fastly = "^0.13"

No source changes to esi. cargo check -p esi --target wasm32-wasip1 compiles clean.

With that referenced from [patch.crates-io] in trusted-server, both Fastly gates pass:

• cargo clippy-fastly — clean under -D warnings
• cargo test-fastly — 166 adapter tests (ESI assembly included), 2290 core, 2 js, 21 openrtb, 3 doctests; 0 failed

So the version range is genuinely the only obstacle, and the resulting build is exercised rather than merely compiling.

[aram356]

Branch pushed to the fork: stackpop/esi@chore/fastly-0.13 (75bfbb396), branched from upstream v0.7.2.

It turned out to be seven lines, not one. The library pin was the blocker, but the six examples pin fastly themselves, so they move with it — leaving them at 0.12 would build each example against a different SDK than the esi it links, which is the same two-copies problem one level down. Still no source changes to esi.

PR #1123 now references that rev via [patch.crates-io], and both Fastly gates pass against it:

• fastly 0.12 drops out of the graph entirely; one copy remains
• cargo clippy-fastly — clean under -D warnings
• cargo test-fastly — 166 adapter + 2290 core + 2 js + 21 openrtb + 3 doctests, 0 failed

The patch in #1123 is temporary and marked as such; it should be dropped once the range bump is released upstream. An upstream PR against fastly/esi has not been opened yet.

[aram356]

esi's own test suite passes against fastly 0.13: 163 passed, 0 failed on wasm32-wasip1 under Viceroy 0.21.0, on the fork branch as pushed.

So the change is verified on both sides — esi's suite against the new SDK, and trusted-server's full CI against the patched esi. That is the evidence an upstream PR would need.