Part of #80171 and follow-up to #80323.

The Phase 2 runtime tool fixture set exists, but it is currently an inventory/reporting lane rather than a hard default-tool parity gate.

Audit snapshot from #80323:

• qa/scenarios/runtime/tools/ contains 20 runtime tool fixtures.
• All 20 fixtures currently include knownBroken metadata because the harness surfaced real Pi/Codex/default-surface drift tracked by QA tool-defaults suite conflates Codex-native tools with OpenClaw dynamic tool parity #80319, [QA harness] mock Pi provider id and apply_patch failure fixture distort parity #80320, and [QA harness] direct message fixture targets messaging-profile tool from coding profile #80321.
• The release runtime-pair lane uses the 12-scenario agentic parity pack, not the full 20-tool fixture set.

Why this matters:

If Codex becomes the default OpenAI runtime, a first-hour gate should prove the default tool surface is both visible and callable under Pi and Codex. Keeping every fixture as known-broken preserves evidence, but it does not yet protect maintainers from regressing default tool availability once the known drifts are fixed.

Acceptance sketch:

• Split runtime tool fixtures into required default tools vs optional/plugin-dependent tools.
• Remove knownBroken metadata from fixed tools and fail the report on any required-tool call/result drift.
• Keep optional tools report-only unless their plugin/provider is explicitly enabled.
• Add release or scheduled coverage for the required default tool set under --runtime-pair pi,codex.
• Tie expected failures to QA tool-defaults suite conflates Codex-native tools with OpenClaw dynamic tool parity #80319, [QA harness] mock Pi provider id and apply_patch failure fixture distort parity #80320, and [QA harness] direct message fixture targets messaging-profile tool from coding profile #80321 until those runtime/tool-surface defects are resolved.