feat(http): replace reqwest with pingora client

[terylt]

Description

PPE currently uses reqwest for all outbound HTTP. Praxis runs on pingora, so shipping PPE with reqwest means two HTTP stacks, two TLS configs, and two connection pools in the same process. We need to be on the pingora client before PPE goes stable.

Three plugins are affected, all doing JSON over HTTPS:

• builtins/plugins/identity-jwt - JWKS fetch (src/config.rs:277)
• builtins/plugins/delegator-oauth - IdP token endpoint POST (src/delegator.rs:167)
• builtins/plugins/elicitation-ciba - backchannel auth and token endpoint POSTs (src/approver.rs:109)

Each builds its own reqwest::Client with default-features = false and rustls-tls.

Pingora's client is lower level than reqwest, so this likely needs a small shared HTTP helper crate rather than three separate ports. Decide that shape first.

Acceptance Criteria

• No reqwest dependency anywhere in the workspace, including dev-dependencies and tests
• A shared HTTP client abstraction the three plugins use, with connection pooling and timeouts configurable per plugin
• TLS stance preserved: rustls, no OpenSSL, no default features pulling in extra transports
• Existing timeout, retry, and error mapping behavior unchanged from the caller's perspective
• jwks_url_e2e.rs and the CIBA and delegator tests pass without loosening assertions
• cargo deny clean
• Plugin config surface unchanged, or the break is documented in CHANGELOG

[terylt]

Dug into this with both repos checked out.

We don't want to take pingora directly because:

PPE must not depend on Praxis. Praxis already depends on PPE (ppe = { package = "praxis-policy", features = ["builtins"] }, praxis Cargo.toml:47). Any PPE to praxis-core edge is circular.

Praxis doesn't use upstream pingora. It's on a fork under renamed packages (praxis Cargo.toml:63):

# Temporary fork: https://github.com/praxis-proxy/pingora
pingora-core = { version = "0.8.2", package = "quixotic-plecostomus-core", features = ["rustls"] }
pingora-http = { version = "0.8.2", package = "quixotic-plecostomus-http" }
pingora-proxy = { version = "0.8.2", package = "quixotic-plecostomus-proxy", features = ["rustls"] }

Cargo treats renamed packages as unrelated crates. So if PPE pulls pingora-core from crates.io, we link two pingora stacks, two TLS configs, two connection pools. That's the exact outcome this issue exists to remove, just with pingora on both sides instead of pingora plus reqwest. And if PPE depends on the fork, our published crate carries a Praxis-specific fork in its public dep tree and our releases gate on that fork's cadence.

Proposal: host-injected transport

Define the trait in PPE, plugins depend on the trait, host injects the implementation. Praxis injects a pingora-backed one. PPE never links pingora.

Not a new pattern here. It's what SessionStore / SessionStoreFactory / MemorySessionStore already do (crates/ppe-apl-runtime/src/session_store.rs:68).

// crates/ppe-core/src/http.rs
#[async_trait]
pub trait HttpTransport: Send + Sync {
    async fn execute(&self, req: HttpRequest) -> Result<HttpResponse, HttpTransportError>;
}

pub struct HttpRequest {
    pub method: http::Method,
    pub url: String,
    pub headers: http::HeaderMap,
    pub body: Bytes,
    pub timeout: Duration,
    pub connect_timeout: Option<Duration>,
    pub max_response_bytes: usize,
}

#[non_exhaustive]
pub enum HttpTransportError {
    Timeout,                 // keeps identity-jwt's is_timeout() branch working
    Connect(String),
    Io(String),
    InvalidRequest(String),
    ResponseTooLarge { actual: usize, limit: usize },
}

Form encoding and basic auth stay caller-side in a small helper rather than being transport concerns. Keeps the trait tiny, and means every transport sees identical bytes. Push encoding into the implementations and two of them can encode differently, which you find out in production.

Registration mirrors register_factory: PolicyEngine::set_http_transport(Arc<dyn HttpTransport>).

No config surface for this. SessionStore lets operators pick kind: valkey in YAML. Which HTTP stack the process uses is a host embedding decision, and putting it in policy YAML would let an operator reintroduce the second-stack problem from a config file. Host-injected only.

The Praxis adapter already exists

Nobody writes a pingora client. praxis_core::subrequest::SubRequestClient is one, and it's better than what reqwest was giving us: pooling, per-call timeout, max_response_bytes, typed errors, and per-peer circuit breaking. The error enum maps almost one to one onto the trait above.

Two gaps for whoever writes the adapter:

• execute takes an &HttpPeer, not a URL, so the adapter owns URL to host/port/TLS/SNI resolution. Praxis has the DNS half in core/src/connectivity/peer.rs. Getting SNI wrong here is a security bug, not a cosmetic one.
• CircuitOpen and AdmissionTimeout have no reqwest equivalent.

This and #29 are related.

Sequencing

Two PRs, two repos.

1. PPE. Trait, hyper default, port all three plugins, suite green with zero reqwest. Self-contained, satisfies every criterion on this issue on its own.
2. Praxis. The pingora-backed adapter. "One HTTP stack in the process" is only actually achieved when this lands.

Suggested criteria changes

Mostly additive to what's there:

• PPE links no pingora crate, forked or upstream
• Transport handles are runtime-agnostic and build pools lazily, with a test that constructs on one runtime and uses on another
• A fake HttpTransport in test code, so timeout and error-mapping assertions stop depending on socket timing
• insecure_http: true plaintext paths still work
• Circuit-breaker behaviour on JWKS decided and written down
• Criterion 4 relaxed if we give CircuitOpen its own code

We will build a default implementation on top of hyper that can be optionally compiled into PPE. This will let PPE operate out of the box, but leave it out for things like praxis.