[dhruv8sh]

Summary

• Turns pull sync into an identity provider that runs in the after-response phase from Collect server-side identity provider EIDs in a single page-load write #1487, so pull-synced partner IDs flow through the same coordinator and KV writes as other providers without adding page latency.
• Mirrors provider-owned bidstream UIDs to a JS-readable __Host-ts-eids-mirror cookie so publisher-side code can read them, on a best-effort basis.

Stacked on #1487; review only the commits on top of it.

Changes

Commit	Change
Run pull sync as an identity provider on navigations	New trusted-server-identity-providers/src/pull_sync.rs; removes core ec/pull_sync.rs / ec/pull_sync_marker.rs and the old post-send pull sync path in the Fastly adapter. Pull-sync providers are built with collect = "after_response", so they only run for an EC whose consented row already exists
Mirror provider-owned bidstream UIDs to a JS-readable cookie	New ec/mirror.rs; ec/finalize.rs, ec/cookies.rs, constants.rs write the __Host-ts-eids-mirror cookie
Make mirroring best effort and fix pull sync validation	Mirror failures no longer fail the response; the mirror cookie is expired only when the browser sent one; pull sync config validation fixes
Stop mirroring ownerless UIDs and re-pulling held pull-sync sources	Only owned UIDs are mirrored; ownerless batch records count as held for pull sync
Keep batch sync for pull-sync partners	Batch sync rejects only sources owned by a configured identity provider, so a partner with both pull sync and an api_token keeps batch sync
Set the mirror cookie only when its value changes	An unchanged mirror emits no Set-Cookie, so returning visitors' pages stay cacheable
Skip identity lookups when the rate limiter cannot count	A rate-limiter error now skips the lookup (as pull sync did before) for every provider
Reject the pull-sync kind in identity provider config	kind = "pull-sync" in [[ec.identity_providers]] is rejected; pull sync comes only from partner config with its token and rate limit
Refuse to key the template cache on the EID mirror cookie	__Host-ts-eids-mirror joins the identity cookies the template cache key refuses
Rotate pull-sync partners hourly	Partners beyond the per-navigation cap still get turns
Docs	Rate-limit rounding, the per-navigation cap and the mirror exposure callout in docs/guide/edge-cookies.md and configuration.md
Tests	Pull-sync results mirrored with their owner, non-navigations leaving the mirror untouched, withdrawn rows expiring it

Behaviour changes from main

• Pull sync timing. Pull sync now runs in the after-response phase, within identity_after_response_budget_ms, and only for an EC whose consented row already exists.
• pull_sync_concurrency is a cap per navigation. It used to be a batch width with every eligible partner pulled; partners now rotate hourly so each gets turns under the cap.
• Rate limits. pull_sync_rate_limit is enforced per minute with a minimum of one on Fastly, so the default of 10 per hour behaves like 60.
• Mirror exposure. Pull-sync UIDs now carry an owner, so for bidstream_enabled partners they reach the script-readable mirror cookie. Previously they lived only in KV.

Closes

Part of #1246 and #1245; the provider implementations that close them come in follow-up PRs.

Spec

Spec: reviewed separately; not included in this PR.

Test plan

• cargo test-fastly && cargo test-fastly-reuse && cargo test-axum && cargo test-cloudflare && cargo test-spin
• All eight clippy aliases
• cargo fmt --all -- --check
• Parity tests, native template build-digest test and clippy, scripts/lint-wasm-clock.sh
• JS tests, format and lint
• Docs format and Markdown prettier check
• ./scripts/test-cli.sh, domain lint against the base branch, CI Node pin guard, docs-proposal scripts
• HTML EOF checks (native harness, Axum and Fastly auction controls)
• Fastly EC integration tests (left to CI)
• Manual testing via fastly compute serve

Checklist

• Feature PRs: spec linked above, ending in a review log of two or more agent review rounds
• Changes follow AGENTS.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses log macros (not println!)
• New code has tests
• No secrets or credentials committed

[ChristianPavilonis]

Summary

This PR moves pull sync into after-response identity collection and adds a bounded, JavaScript-readable mirror of provider-written bidstream UIDs. One startup-validation issue needs addressing; there is also an opportunity to avoid a redundant KV read on steady-state navigations.

The inline comment is prose-only: the proposed fix and regression coverage touch lines outside the diff, so there are no one-click suggestions.

Blocking

🔧 wrench

• Reject malformed pull tokens during startup — see inline at crates/trusted-server-identity-providers/src/pull_sync.rs:59-60.

Cross-cutting / body-level findings

♻️ Avoid the follow-up KV read when all lookups were skipped

Introduced by crates/trusted-server-identity-providers/src/lib.rs:169-182; affected helper: crates/trusted-server-core/src/ec/after_response.rs:76-79.

When every pull-sync source already holds a UID, dispatch produces Skipped(NotDue) results. Those results are nonempty, so the follow-up helper rereads KV despite having nothing to persist. Moving existing pull-sync partners into this path adds an avoidable read on every eligible returning navigation.

Import LookupStatus and SkipReason alongside LookupResults, then replace the helper's empty-results guard with:

    if lookups.iter().all(|lookup| {
        lookup.entries.is_empty()
            && lookup.cleared.is_empty()
            && lookup.status != LookupStatus::Skipped(SkipReason::OptedOut)
    }) {
        return AfterResponseOutcome::Unchanged;
    }

This preserves writes that remember provider opt-outs.

Apply manually — the helper, imports, and regression test are outside the diff.

Verification

• A focused scratch reproduction confirmed that a newline-containing pull token passes runtime config validation but prevents construction of the coordinator for both an invalid and an otherwise valid partner.
• A counting-store scratch reproduction confirmed that all-NotDue results still cause one KV read in the follow-up helper.
• Both reproductions passed. Scratch changes were removed and the worktree was restored to the reviewed head.
• The proposed fixes have not been compiled or run through the full local gate.

CI Status

• integration tests: PASS
• browser integration tests: PASS
• integration tests (Fastly EC lifecycle): PASS
• trace runtime and browser acceptance: PASS
• cargo fmt: PASS
• cargo test (axum native): PASS
• cargo test (cross-adapter parity): PASS
• format-docs: PASS
• worker-deadlines (spin): PASS
• worker-deadlines (cloudflare): PASS
• ts dev lint domains (changed lines): PASS
• cargo test: PASS
• format-typescript: PASS
• cargo test (ts CLI, native) (macos-latest): PASS
• HTML EOF runtime (Fastly): PASS
• cargo check/build/test (spin native + wasm32-wasip1): PASS
• CLAUDE.md symlink guard: PASS
• docs-proposal scripts: PASS
• CI Node pin guard: PASS
• cargo test (ts CLI, native) (ubuntu-latest): PASS
• cargo check (cloudflare native + wasm32-unknown-unknown): PASS
• prepare integration artifacts: PASS
• vitest: PASS

No required checks were reported by the required-check query.

[ChristianPavilonis]

🔧 Reject malformed pull tokens during startup

A pull token containing a newline passes runtime config validation but fails here. Because provider construction collects into one Result (src/lib.rs:169-182), that single invalid token prevents every after-response provider from running. The request-time caller merely logs the failure.

Reject invalid resolved tokens in crates/trusted-server-core/src/ec/registry.rs during startup, while retaining the disabled-partner bypass:

    if require_nonempty_token
        && token_value.is_some_and(|value| {
            value.trim().is_empty()
                || http::HeaderValue::try_from(format!("Bearer {value}")).is_err()
        })
    {
        return Err(Report::new(TrustedServerError::Configuration {
            message: "ts_pull_token must be nonempty and valid in an HTTP Authorization header"
                .to_owned(),
        }));
    }

Add regression coverage for invalid enabled tokens and disabled partners. Validate resolved secret values at runtime config load, not secret-store key references during deploy validation.

Apply manually — the fix and regression tests touch lines outside this PR's diff hunks.

A focused scratch reproduction confirmed the startup-acceptance/coordinator-failure sequence with two partners. The proposed fix itself has not been compiled.