Publish a strict downstream receipt verification contract

[briananderson1222]

Learning source

An independent Evals evidence consumer needed to validate Dispatch receipts without trusting producer-authored JSON. Re-implementing the TypeScript interface downstream initially missed typed attempt fields, totals reconciliation, retry semantics, and one-invocation binding rules.

Outcome

Publish a versioned, runtime-usable receipt verification contract that downstream evidence systems can consume without copying Dispatch internals.

Acceptance

• Export a strict schema or zero-dependency verifier for DispatchReceipt v1, including nested attempts, authorization, and physical-batch evidence.
• Reject unknown fields, invalid enums/types, empty identities, malformed counters, and inconsistent aggregate totals.
• Document retry and durable reservation/authorization settlement semantics.
• Expose canonical receipt/binding identities suitable for replay detection without exposing credentials or request content.
• Provide valid success/retry/batch fixtures and mutation-negative conformance fixtures.
• Keep authorization-ledger authenticity distinct from structural receipt validity.

Consumer discovered in kontourai/evals#141.

[briananderson1222]

Sequencing input from the 2026-08-01 suite audit (station#1555 context): receipts today record attempts but not routing decisions — a consumer can see what was tried and cannot reconstruct why a candidate was chosen or rejected (station#1556 is the station-side symptom: no-eligible-candidates reported for candidates that were attempted). When the strict downstream verification contract lands here, the decision record (constraint evaluated, per-candidate verdict with named reason, selection) should be part of the verifiable surface, not just the attempt list — station's portable-project-identity §6.1 (docs/design/portable-project-identity.md) already specifies the consumer shape: "the Dispatch receipt cites the constraint, every candidate's answer including the rejections, and the selection."

Planning note: this issue should land before station#1504 (contribution projections + constraint-based delegate_task targeting) consumes it, or #1504 ships a receipt the contract will later invalidate.