Optional evidence[] predicate for decision receipts: schema + verified reference receipt

[UseTruth]

Follow-up to the discussion in VeritasActa/Acta#3 (@tomjwxf), converging on ACTA rather than forking.

This adds an optional evidence[] predicate that carries the evidentiary basis of a decision receipt: not just which decision, but what it rested on and whose attestation that is. It is additive and safely ignorable by verifiers that do not understand it.

Files (self-contained under evidence-predicate/, easy to relocate, e.g. the schema to repo root next to knowledge-unit.schema.json):

• evidence-dimension.schema.json — JSON Schema (draft 2020-12) for the predicate.
• receipt-with-evidence.example.json — a signed reference decision_receipt carrying the predicate.
• verification-key.json — public verification key(s) (JWK + hex). TEST keys, not production.
• README.md — how it maps to the review, and how to verify.

Both refinements from the issue are folded in:

• Closed vocabularies: state in satisfied | unverified | stale | failed; dimension in data_rights | provenance | freshness | contradiction (core), plus an x-<vendor>-<name> form for experimental dimensions so unknowns stay ignorable.
• source is a structured { issuer, (key | ref) } with an optional kid, so the relying party can pin whose attestation this is. issuer MUST be independent of the runtime being gated, and the predicate composes with the signer-derived tier rather than restating it.

The reference receipt verifies under @veritasacta/verify (v2 decision_receipt, tier T1 ed25519-signature, jcs-canonicalization):

npx @veritasacta/verify evidence-predicate/receipt-with-evidence.example.json \
  --key <receipt_signer_hex from verification-key.json>

Two open questions from the issue, with defaults so this is not blocking:

1. Location: payload.evidence.dimensions[] (composes with the existing payload.evidence) vs a top-level payload.evidence[]. Same predicate either way.
2. Extension form: x-<vendor>-<name> vs a registry convention you prefer.

I have deliberately not touched the draft .xml/.txt here, so you can integrate the section into the -next signed-receipts draft however you see fit. Happy to co-author.