feat: add embodied action receipt fixtures

[carloshvp]

Summary

Adds a small fixture-style embodied-action receipt example for offline verification of externally consequential action evidence.

This complements:

• cmcp#339 Embodied Action Evidence Profile
• trace-spec#66 verification.action_receipts axis

What changed

• Added embodied-action-receipts/ with deterministic JSON fixtures for:
  • accepted signed receipt chain
  • missing required receipt
  • invalid signature
  • valid signed controller rejection
• Added verify_receipts.py, an offline verifier that checks:
  • recomputed action_ref
  • cMCP call_id / TRACE session binding
  • pinned controller public key
  • Ed25519 receipt signatures
  • hash-chain ordering
  • distinction between invalid receipts and valid rejected outcomes
• Added generate_fixtures.py for reproducible fixture generation from a deterministic public test seed.
• Added unit tests and wired them into CI.
• Listed the example in the root README.

Why

For embodied AI, verification.action_receipts: required should mean action-level receipt evidence is offline-verifiable and bound to the session/call. It should not imply physical completion, controller safety, or functional-safety certification.

The controller-rejected fixture makes that boundary concrete: a signed rejection is valid evidence, but it is not proof that the physical action completed.

Validation

• python3 -m unittest discover -s embodied-action-receipts/tests -v
• python3 embodied-action-receipts/verify_receipts.py embodied-action-receipts/fixtures/valid-chain.json
• python3 embodied-action-receipts/verify_receipts.py embodied-action-receipts/fixtures/controller-rejected.json
• repo JSON validation: python3 -m json.tool over all JSON files
• repo YAML validation via pyyaml
• git diff --check

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	LOW
Credential	MEDIUM
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[imran-siddique]

Nice self-contained offline verifier + deterministic fixtures. Approving.

Fixtures are self-consistent. I recomputed action.action_ref from the canonical (agent_id, action_type, action_scope, action_timestamp) preimage and it matches sha256:6572d670…0b21f across all four fixtures. The CI unittest (test_fixtures_match_expected_results) asserts verify_fixture() == expected for every fixture, which re-derives the action_ref, verifies each Ed25519 receipt signature against the pinned controller key, and walks the prev_receipt_hash chain — so green CI is a real self-consistency proof here, not just a smoke test.

Signing/preimage rules line up. generate_fixtures.py signs over canonical_bytes of the receipt minus signature, and verify_receipts.py verifies over receipt_preimage (same minus-signature canonical form). The chain hash is taken over the full signed receipt on both sides, so the sha256:997a9dd7…cd338 link in the two-receipt chains is consistent.

Outcome coverage is good: accepted chain, missing-required-receipt, invalid signature (last b64 char flipped, …GDw → …GDA), and the controller-rejected fixture that correctly makes the point that a signed rejection is valid evidence of a negative outcome, not a verifier failure.

One follow-up worth a future PR (not blocking): verify_receipts.py has branches for call_id_mismatch, trace_id_mismatch, action_ref_mismatch, and chain_mismatch (reordered/tampered prev_receipt_hash), but no fixture exercises a wrong-binding / broken-chain case — only the signature tamper is covered. A wrong-call-id.json or broken-chain.json fixture would lock in those binding checks the same way signature-mismatch.json locks in signature verification.

CI green (validate, embodied-action-receipts, industrial-embodied-ai). Approving.