architecture: centralize capture admission and evidence proof authority

[Brad-Edwards]

Objective

Centralize the capture-admission and emitted-evidence proof pipeline so new capture dimensions, output contracts, and evidence consumers cannot acquire divergent authority semantics.

Context

Issue #1112 closes the known fail-open paths across manifest offers, planning, trial compilation and realization, runtime authorization, and post-run evidence validation. Its review history showed that the same trust invariant currently spans several models and call sites. This issue is follow-up hardening; no known #1112 defect is moved here.

Scope

• Introduce a first-class validated-evidence binding/result type and make task, run, study, metric, and condition consumers accept that proof object rather than reconstructing authority from reference metadata.
• Pair every evidence-eligible output contract with both its published JSON Schema and owning semantic validator in one governed registry; fail closed when either side is absent.
• Centralize capture demand/offer dimension definitions and generate parity or property tests covering projection, round-trip conversion, matching, diagnostics, and every pre-effect ingress.
• Reduce duplicate mapping logic between Pydantic contracts, backend protocol dataclasses, processor demands, and runtime representations without weakening the closed contract boundaries.

Acceptance criteria

• Evidence satisfaction has one typed proof result consumed by all authoritative downstream checks.
• Every evidence-eligible output contract is atomically registered with schema and semantic validation.
• Adding a capture dimension fails tests unless projection, manifest conversion, matching, and diagnostics all cover it.
• Planning, trial compilation, trial realization, runtime submission, and study analysis share invariant-level conformance tests.
• Negative tests prove reference metadata cannot substitute for validated emitted content.
• No compatibility fallback, backend-specific exception, or weakening of runtime: reject backends whose capture manifests do not satisfy scenario requirements #1112 fail-closed behavior is introduced.

References

• runtime: reject backends whose capture manifests do not satisfy scenario requirements #1112
• ADR-064
• ADR-066