Admit origin compatibility fingerprints before Cloudflare multi-origin failover #83

Goal

Before Cloudflare can route or fail over across AWS/GCP Kubernetes, GCP Cloud Run, BeamScale, and Scintilla origins, require a bounded compatibility fingerprint from each candidate origin. A healthy TCP/HTTP endpoint is not sufficient evidence that it can safely serve the same Zed contract or database epoch.

Depends on zed-pkg/zed-interfaces#149 for the canonical origin-set authority.

Compatibility fingerprint

Define a credential-free machine response, sourced from the deployed server build, that binds at least:

• stable origin id from the admitted OriginSetV1;
• immutable server/source/build receipt;
• Zed interfaces / route contract digest or compatibility epoch;
• database/schema compatibility epoch where the route family requires persistence compatibility;
• supported route families;
• runtime/provider identity (Kubernetes, Cloud Run, BeamScale, Scintilla; AWS/GCP as applicable);
• deployment generation / release identity;
• timestamp only if it is informational and not part of reproducibility identity.

Do not expose secrets, internal database URLs, private backend addresses, bearer material, or environment dumps.

Cloudflare admission semantics

• Load only origins present in the admitted OriginSetV1 document.
• Probe/cache fingerprints under a bounded deadline and bounded freshness lifetime.
• A candidate with an unknown/malformed fingerprint is not eligible for routed reads or writes.
• A candidate with an incompatible contract/database epoch is not eligible even when /healthz is 200.
• Compatibility admission happens before hedged/failover routing.
• Public package recovery may continue to use the already-reviewed independent GitHub/native/CDN fallback paths when no compatible Zed origin is available; compatibility failure must not silently widen private access.
• Private/auth/account/write routes fail closed when no compatible authorized origin exists.
• Distinguish transport-unavailable, unhealthy, fingerprint-invalid, and fingerprint-incompatible outcomes in redacted structured evidence.

Rollout / skew tests

Cover at least:

1. same release on two origins;
2. new server + old compatible server;
3. incompatible interface/route epoch;
4. incompatible DB/schema epoch;
5. stale cached fingerprint after origin redeploy;
6. origin that reports healthy but lacks the requested route family;
7. malformed/oversized fingerprint;
8. fingerprint endpoint unavailable;
9. Cloud Run cold start followed by successful compatible admission;
10. BeamScale/Scintilla origin present but capability-ineligible for a requested route.

Server follow-up

Open/coordinate a server-side implementation item in zed-api-server.rs (and shared server core if appropriate) so every deployed origin emits the fingerprint from immutable build/contract inputs rather than hand-authored environment strings.

Non-goals

• no user credential forwarding;
• no write hedging;
• no inference that a healthy origin is compatible;
• no production multi-origin enablement until exact-head Worker/runtime conformance is green.