Keep native fuzz-engine locks out of generic coverage dependency images #762

Outcome

Central OpenCode coverage evidence installs only dependencies needed to import and measure selected production/test code. Native coverage-guided fuzz-engine locks remain in repository fuzz workflows and are not materialized into the generic Python coverage image.

Problem

The trusted-base Python lock materializer currently selects every hash-pinned requirements*.txt candidate. In contextual-orchestrator, this includes fuzz/requirements-atheris.txt. The generic coverage image runs a newer CPython and attempts to install a platform/interpreter-specific libFuzzer binding even though no fuzz target is executed, converting an irrelevant toolchain mismatch into a CHANGES_REQUESTED review and blocking the dependency repair that would make later fuzz installations portable.

Scope

• classify exact native fuzz-engine lock names as coverage-incompatible toolchain inputs;
• exclude requirements-atheris.txt from generic coverage dependency materialization regardless of directory depth;
• continue materializing fuzz property/test locks such as requirements-property.txt when they are hash-pinned;
• retain exact-base Git reads, hash enforcement, no-PR-input network boundary, deterministic ordering, and fail-closed malformed-tree handling;
• add real temporary-repository tests proving the native engine is excluded while property/test dependencies are retained;
• add 100% statement/branch coverage and docstrings for the changed helper;
• document the boundary and current official Atheris/PyPA evidence with APA 7 references;
• update CHANGELOG.md;
• do not change OpenCode, Noema, Strix, NVIDIA NIM, or reviewer credential names/scopes.

Acceptance

• focused and full central tests pass;
• security, CodeQL, Semgrep, dependency, secret, SBOM, Scorecard, OpenCode, and Noema exact-head gates pass;
• ContextualWisdomLab/contextual-orchestrator#96 can obtain coverage evidence from its existing protected base without installing Atheris;
• no coverage dependency is selected from pull-request-mutated content.

Refs ContextualWisdomLab/contextual-orchestrator#76 and #96.