Providers in the shared app, awaited before finalization #1591

Summary

Providers in the shared app, awaited before finalization; only follow-up writes after the response; verified on Fastly with ID5.

Part of #1558, server-side identity on every adapter. Plan ID T11, planned in wave 6 (MVP: Fastly and Axum); priority P1, size M. Design: spec; order and dependencies: plan.

Requirements

ID-4 Providers on every supported adapter

Lookups start at navigation alongside the origin fetch, share one deadline, and are awaited before finalization, so their IDs reach the record and the cookies of the same document response. A page load writes the record once.

ID-5 After-response work

Only pull sync and guarded follow-up writes run after the response is sent: after send on Fastly, a task drained on SIGTERM on Axum, waitUntil on Cloudflare. On Spin the work runs before the response (DEC-14; DEC-16 rules out skipping it).

WB-1 Document and EC route responses only

Identity cookies are set on top-level HTML document responses and on EC route responses (ID-9), on every supported adapter.

Current state

What the code does today, from the design's survey at the revisions it names:

• WB-1: main mints ts-ec on Fastly navigations, and the RC adds Axum.

Acceptance criteria

• ID-4: A mock provider that answers within the deadline has its ID in the record and in the mirror cookie of that navigation's response
• ID-4: One that misses the deadline is skipped and does not delay the response past it
• ID-5: On Fastly, Axum and Cloudflare a follow-up write recorded after send is in the record before the next navigation, and on Axum SIGTERM waits for it (A3). On Spin the follow-up write lands before the response
• WB-1: Identity Set-Cookie headers appear on navigation and EC route responses and never on asset or other API responses

Dependencies

Blocked by:

• One identity app in core for every adapter #1600 One identity app in core for every adapter (new in this plan)
• Integration-branch tag with the Fastly and Axum parts of EZI-1 edgezero#490 Integration-branch tag with the Fastly and Axum parts of EZI-1 (new in this plan)
• PR Collect server-side identity provider EIDs in a single page-load write #1487 Collect server-side identity provider EIDs in a single page-load write

Blocks:

• Identity features pass on Axum from the shared app #1581 Identity features pass on Axum from the shared app (new in this plan)
• Identity features pass on Cloudflare from the shared app #1596 Identity features pass on Cloudflare from the shared app (new in this plan)
• EC route in the shared app, verified on Fastly #1598 EC route in the shared app, verified on Fastly (new in this plan)
• LiveRamp per DEC-9: Custom ID, enablement and checks on Fastly and Axum #1601 LiveRamp per DEC-9: Custom ID, enablement and checks on Fastly and Axum (new in this plan)

Related pull requests

• Collect server-side identity provider EIDs in a single page-load write #1487 Collect server-side identity provider EIDs in a single page-load write: must merge first.

  Fixes the plan asks of Collect server-side identity provider EIDs in a single page-load write #1487

  Every item from 4e7a6e02b is still open. Rebase onto Make shared EC persistence awaitable #1526 and Cut Trusted Server over to EdgeZero PR 275 #1506 (8 and 17 files conflict). Await lookup collection in the async finalize: main.rs:699 calls block_on inside a function Make shared EC persistence awaitable #1526 wraps in block_on (main.rs:550, :577), and run_after_response_lookups does the same at :793 and :811. Move per-request lookups out of the thread_local (app.rs:414-424). Keep saving /auction body EIDs (ID-8): the test at finalize.rs:1365 asserts they are dropped and the PR's own spec now calls that intended, so the comment argues against that spec line. Send lookups through EdgeZero's HttpClient: Cut Trusted Server over to EdgeZero PR 275 #1506 deletes platform/http.rs, and its outbound_client().start_batch_until has the same start-then-gather shape.