Add manifest-driven fixture selection for degradation curves

[ProfRandom92]

Motivation

• Allow DegradationCurveGenerator to select fixtures by manifest-registered family so multiple fixture families with the standard degradation levels can be used without changing scoring or visualization.
• Preserve existing layered admissibility behavior while providing a reusable, deterministic selector for other families.

Description

• Add fixtures_for_manifest_family(self, family, levels=LAYERED_CURVE_LEVELS, manifest_path=MANIFEST_PATH) to src/validation/degradation_curve_generator.py that loads the manifest, filters by family, selects only requested degradation_levels in explicit order, and returns Path tuples.
• The selector raises ValueError for missing requested levels, duplicate family+level entries, or missing path values to fail fast on manifest issues.
• Keep fixtures_for_layered_admissibility_curve(...) as a backward-compatible wrapper that calls the new generic selector with LAYERED_CURVE_FAMILY and LAYERED_CURVE_LEVELS.
• Add focused tests in tests/test_degradation_curve_generator.py to verify selection for both coding_workflow_pr_review and incident_response_page_triage, wrapper compatibility, and error cases for missing family/level and duplicate entries.

Testing

• Ran pytest tests/test_degradation_curve_generator.py -q and observed 18 passed for the updated file-level tests.
• Ran pytest tests/test_manifest_fixture_families.py -q and pytest tests/test_fixture_manifest.py -q and observed 3 passed and 8 passed, respectively.
• Ran npm run check (which runs layout, typecheck, validate, build, and the full pytest suite) and observed the full test run succeed with 207 passed and npm run check completed successfully.

---

Codex Task

[gemini-code-assist]

Code Review

This pull request introduces a more flexible fixtures_for_manifest_family method in DegradationCurveGenerator to support multiple fixture families beyond the default layered admissibility curve, along with comprehensive unit tests for these new capabilities. The reviewer correctly identified a performance concern regarding redundant disk I/O and JSON parsing, suggesting that caching the manifest content would better align with the project's high-efficiency and industrial-grade performance requirements.

[gemini-code-assist]

The manifest is re-loaded and parsed from disk on every call to fixtures_for_manifest_family. In a high-efficiency context (as emphasized in the Repository Style Guide), especially when generating multiple curves or running a large test suite, this redundant I/O and JSON parsing can become a performance bottleneck. Consider caching the manifest content to improve efficiency.

References

1. The project mission emphasizes high-efficiency technical-log compression and industrial-grade performance. ^(link)