JWKS cache uses std::time::Instant — panics on wasm32-unknown-unknown

[aram356]

Problem

crates/mocktioneer-core/src/verification.rs uses std::time::Instant for the JWKS cache TTL and std::sync::Mutex / LazyLock for the cache map:

use std::sync::{LazyLock, Mutex};
use std::time::{Duration, Instant};

const JWKS_CACHE_TTL: Duration = Duration::from_mins(10);
static JWKS_CACHE: LazyLock<Mutex<HashMap<String, JwksCache>>> = ...;

Instant::now() has no monotonic clock source on wasm32-unknown-unknown (the Cloudflare Workers target) and panics at runtime. The code compiles cleanly, so the wasm-target compile-check in CI does not catch it.

Why it is currently hidden

The signature-verification path only runs for /openrtb2/auction requests carrying a trusted_server ext block. The new Cloudflare wasm contract test (crates/mocktioneer-adapter-cloudflare/tests/contract.rs) only exercises GET / and GET /pixel, so the Instant::now() call is never reached under wasm-bindgen-test.

A real signed auction request to the Cloudflare adapter would panic.

Scope

• Surfaced during review of Adopt edgezero strict-clippy gate and PR #257 API #108 (PR review by @prk-Jr). Pre-existing — not a regression introduced by that PR.
• The Fastly target (wasm32-wasip1) provides a clock, so Fastly is unaffected; this is specific to wasm32-unknown-unknown.

Suggested fix

• Replace Instant with a wasm-compatible time source — e.g. the web-time crate (drop-in Instant replacement that edgezero already depends on), or thread a timestamp through RequestContext.
• Audit std::sync::Mutex use under wasm32-unknown-unknown; LazyLock<Mutex<…>> is acceptable on the single-threaded wasm runtime but should be confirmed.
• Add a Cloudflare contract test that exercises the signed-auction path so the panic is caught by CI.

Acceptance criteria

• JWKS cache TTL works on wasm32-unknown-unknown without panicking.
• A Cloudflare wasm contract test covers the signature-verification path.