scientific(coverage): remove aggregate claim boolean from public assessment API #743

Finding

#742 removed the pass-like supports_calibration_claim field/accessor from persisted CoverageCalibrationEvidenceRecord because numerical-failure acceptability is intentionally undeclared. The same aggregate boolean still remains public on CoverageCalibrationAssessment, and coverage_calibration_design_contract.rs treats it as an asserted contract.

That leaves a second machine-readable promotion surface: any in-process consumer can call assess_coverage_calibration(...) and receive supports_calibration_claim() == true whenever successful-DGP coverage is within [0.91, 0.98] and coverage MCSE is <= 0.005, without any prospective policy deciding whether the unconditional numerical-failure denominator is acceptable. Removing the wire field while retaining the equivalent public assessment API does not fully repair the claim-semantics boundary.

This is not a request to invent or infer a failure-rate threshold.

Required RED / repair

• add a compile-contract RED proving the aggregate public claim method must be absent;
• remove CoverageCalibrationAssessment::supports_calibration_claim() rather than renaming it to another pass-like aggregate;
• keep coverage_within_practical_band() and monte_carlo_precision_sufficient() as separate component decisions;
• keep attempted/success/failure counts and failure rate available; do not alter numerical arithmetic;
• update tests so they assert component decisions and denominator evidence, not an aggregate promotion flag;
• update CHANGELOG and fix(release): bind fail-closed reconstructable topic-lineage results (#638) #639 authority text, and hand off shared TRACEABILITY/product-gap wording to docs(ddd): restore queue authority and bounded-context ownership #435;
• do not claim this executes or passes the 10,000-DGP study.

Boundary

This is a public API/claim-semantics repair inside validation_core. It does not change the coverage estimand, interval construction, validation-design fingerprint, DGP scenario/seed schedule, outcome ledger, persistence schema v6, or release authority. A future full scientific acceptance decision still requires a prospectively defined failure-rate policy, if one is required, plus the actual exact-head 10,000-DGP evidence.

Refs #639 #680 #725 #741 #742.