docs: Tutorial 33 — Offline-Verifiable Decision Receipts (microsoft#1197)

* docs: add Tutorial 33 — Offline-Verifiable Decision Receipts

Teaches the decision-receipt layer that sits between internal audit logs
(Tutorial 04) and artifact signing (Tutorial 26): per tool-call Ed25519
signatures over JCS-canonical payloads, hash-chained across the session,
verifiable offline by any party with the public key.

Mirrors the existing `examples/protect-mcp-governed/` (PR microsoft#1159) and
`examples/physical-attestation-governed/` (PR microsoft#1168) reference code,
uses their exact APIs, and cross-references Tutorials 01, 04, 07, 08,
12, 26, and 27.

Adds two entries to docs/tutorials/README.md:
- Supply Chain Security section (alongside 25, 26, 27)
- "Enterprise compliance" learning path step 6

Standards covered: RFC 8032 (Ed25519), RFC 8785 (JCS), Cedar (AWS),
IETF draft-farley-acta-signed-receipts.

* docs: strengthen Tutorial 33 with SLSA integration and anchoring primitives

Four additions landing after the initial PR:

1. Receipt Lifecycle ASCII diagram in "The Receipt Format" section.
   Visualizes mint → JCS canonical → Ed25519 sign → store → verify so
   readers can see why the determinism invariant holds.

2. A real Cedar policy block in §4 (Composing with Cedar Policies).
   Previously the section described the CedarDecision API shape without
   showing what a policy producing one actually looks like. Now shows a
   10-line permit/forbid policy and links out to cedar-for-agents for
   the full schema generator.

3. Neutral anchoring primitives subsection in §6 (Cross-Implementation).
   Names Sigstore Rekor and in-toto attestations as the cross-org
   verification fabric beyond the four implementations. References
   sigstore/rekor#2798 and in-toto/attestation#549.

4. New §7 "Emitting Receipts as SLSA Provenance". When an AI agent is
   itself the builder, the receipt chain IS the per-step build log.
   Shows the exact byproducts JSON shape for carrying a receipt chain
   inside a SLSA provenance v1 attestation, referencing the draft
   agent-commit build type at refs.arewm.com/agent-commit/v0.1 and the
   active slsa-framework/slsa#1594 and microsoft#1606 discussions.

No new dependencies. All APIs still verified against the merged
examples/protect-mcp-governed/ and examples/physical-attestation-governed/
reference code.

* docs(tutorial-33): add sidebar on operator-signed vs authority-chain modes

Per @aeoess review on microsoft#1197: the four implementations listed in the
cross-implementation section make different identity-binding choices
that matter for deployment selection. This sidebar names them
explicitly so readers evaluating receipts for their environment can
pick the right mode.

- Operator-signed mode (protect-mcp, protect-mcp-adk, sb-runtime):
  sufficient for internal audit, single-regulator evidence, single-
  tenant compliance. The signer is the operator's supervisor hook.
- Authority-chain-referenced mode (asqav / APS governance hook):
  additionally required for cross-org agent commerce, multi-tenant
  regulated environments, and use cases where principal authority is
  itself auditable. Receipts reference a delegation-chain root.

Both modes verify against @veritasacta/verify and use the same outer
receipt structure; the distinction is the presence of an optional
delegation_chain_root field in the payload.

Cross-references arewm/refs.arewm.com#1 for the parallel authority-
chain attestation proposal as a SLSA byproduct.

---------

Co-authored-by: tommylauren <tfarley@utexas.edu>

Author: tomjwxf