Add WordPress adversarial adapter and vulnerable runtime campaigns

[chubes4]

Problem

The generic #2014 contracts deliberately do not embed WordPress grammars, policies, hooks, or transport special cases. A WordPress extension adapter is still required to turn them into end-to-end security and correctness campaigns inside disposable WP Codebox runtimes.

Scope

• Register WordPress-owned mutators for REST, AJAX, XML-RPC, blocks, shortcodes, serialized values, options/meta, files, cron, CLI, roles/capabilities, and multisite membership.
• Register generic-oracle adapters for authorization/nonce/tenant isolation, injection/execution indicators, transactional consistency, duplicate effects, fail-open behavior, filesystem escape, and secret leakage.
• Intercept WordPress HTTP transports using the generic transport-fault model and publish exact/emulated/unsupported fidelity.
• Add faithful PHP/WordPress and cron clock controls; report database clock support independently.
• Emit bounded hook, route, query, filesystem, cache, lock, memory, CPU, and duration novelty signals.
• Add intentionally vulnerable neutral plugin and theme fixtures for authorization, injection, state corruption, true races, external-service failure, and UI-state defects.
• Run disposable integration/E2E campaigns that automatically discover and minimize every fixture defect and replay stable findings.

Acceptance criteria

• Fixtures run only inside disposable runtimes with network denied by default.
• Campaigns prove deterministic concurrent replay, service failure/recovery, minimized browser journeys, and stable fingerprints.
• Every finding has a sealed, redacted replay bundle with exact runtime/component provenance.
• No WordPress-specific name or policy enters runtime-core.

Refs #2014