Add injectable server-side clock control for WordPress adversarial campaigns

[chubes4]

Problem

WP Codebox adversarial campaigns can freeze and advance browser time, but the WordPress adapter explicitly reports PHP/WordPress runtime time and database time as unsupported. Stateful token, nonce, session, cache-expiry, scheduler, and retry workflows therefore cannot be tested deterministically at expiration boundaries. Sleeping in tests is slow and nondeterministic, and browser-only clock control does not affect server behavior.

Goal

Provide a generic, capability-negotiated server-side clock surface for disposable WordPress runtimes.

Acceptance criteria

• Recipes/adversarial actions can freeze, advance, skew, and restore the WordPress runtime clock.
• The capability reports fidelity independently for PHP/runtime, WordPress APIs, scheduler, and database time.
• Each case restores its baseline through checkpoint/reset and cannot leak clock state into another case.
• Runtime functions used by supported code paths observe the injected time without requiring product-specific logic in WP Codebox.
• Unsupported direct/native time consumers fail closed with explicit capability evidence rather than silently claiming deterministic coverage.
• Replay artifacts include the normalized clock schedule without serializing machine-local data.
• Deterministic tests cover expiration boundaries, replay, reset, and mixed browser/server clock behavior.

Architecture

Keep the core contract backend-neutral. The WordPress Playground adapter owns the concrete injection mechanism and declares exact versus emulated surfaces. Product-specific token/session semantics remain downstream.

AI assistance

• Model: GPT-5.6 Sol
• Tool: OpenCode
• Used for: Inspecting the existing adversarial clock capability boundary and drafting this reusable runtime proposal. Chris Huber remains responsible for the issue and resulting changes.