Avoid no-op EC KV reads in post-send pull sync

[ChristianPavilonis]

Summary

Avoid EC identity-graph KV reads when post-send pull sync has no work to perform.

dispatch_pull_sync currently reads the EC row before it checks whether any partners have pull sync enabled. When pull-enabled partners do exist, it reads the row on every eligible real-browser response even when every partner UID is already present. The work happens after response delivery, so it does not gate response bytes, but it still consumes KV operations and extends Compute instance time.

Proposed direction

1. Resolve pull-enabled partners before reading KV and return immediately when the set is empty.
2. Add a bounded completeness mechanism, such as a short-lived browser marker, so fully synced users can skip no-op KV checks.
3. Preserve the current consent gate, missing-UID-only behavior, partner rate limits, and best-effort post-send failure policy.

Out of scope

Request-scoped reuse of (KvEntry, generation) across auction, finalize, and pull sync belongs exclusively to #851. This issue must not introduce another request-scoped EC cache or duplicate that work.

Acceptance criteria

• No pull-enabled partners results in zero EC KV operations.
• A user known to be complete for the current pull-partner set can skip the initial EC KV read independently of request-scoped reuse from Thread the KV EID read through the request and fix the EC TTL decay bug #851.
• Missing, expired, or invalid completeness state falls back safely to KV.
• Partner configuration changes cannot leave a user permanently marked complete against the old partner set.
• Incomplete users continue to dispatch only eligible partners and persist returned UIDs with CAS protection.
• Unit tests cover no-partner, complete, stale-marker, partial, and KV-failure cases.

Relevant code

• crates/trusted-server-core/src/ec/pull_sync.rs
• crates/trusted-server-adapter-fastly/src/main.rs