Move optional workload systems out of the mandatory runtime core

Parent: #2429

## Problem

`runtime-core` now owns substantial fuzz-suite execution and builders, adversarial campaigns, benchmark contracts/substrates, WordPress discovery plans, browser exploration contracts, and specialized quality artifacts. `runtime-playground` and the CLI contain their corresponding runners and commands.

These systems are valuable, but they are optional workloads built on Codebox. Making all of them part of the mandatory core contract and CLI expands dependencies, commands, schemas, tests, documentation, and release risk for every consumer.

The architecture already says Codebox is not an evaluation harness. Core should provide composable runtime primitives; workload packages should provide evaluation policy and orchestration.

## Desired shape

Keep generic primitives in core:

- bounded command execution;
- observations and evidence references;
- transport-fault and service-control interfaces where backend-neutral;
- snapshots/checkpoints;
- artifact integrity and provenance;
- runtime capability negotiation.

Move optional systems into independently built extension packages inside the monorepo, beginning with:

- fuzzing and WordPress fuzz-suite builders;
- adversarial campaign orchestration;
- benchmark orchestration and scoring-oriented contracts;
- specialized visual-comparison and adaptive-exploration policy above generic browser capture.

## Acceptance criteria

- The default core/runtime/CLI can execute a contained WordPress command without loading optional workload packages.
- Optional workload packages depend on public Codebox contracts and register commands/capabilities through an extension mechanism.
- Generic browser capture and runtime observations remain available without importing quality-suite policy.
- Fuzz, adversarial, benchmark, and specialized visual systems have independent builds and tests.
- Existing public workflows migrate before old core commands and exports are removed.
- `runtime-core` has a documented size/responsibility budget preventing workload policy from returning to the mandatory package.

## AI assistance

- **Model:** OpenAI gpt-5.6-sol
- **Tool:** OpenCode
- **Used for:** Classified mandatory runtime primitives versus optional workload systems and drafted the extension extraction tracker under Chris Huber's direction.

Start by mapping the optional systems currently owned by runtime-core, runtime-playground, and the CLI, separating generic runtime primitives from workload policy. Review the existing public contracts, commands, capabilities, exports, and tests before defining extension package boundaries. Done means optional packages build and test independently, existing workflows migrate, and the acceptance criteria are met without loading workload policy in the default core/runtime/CLI.

Written by the indexing model from the issue text.