Trust layer: verifiable capsule receipts with CCF write-receipt anchoring

Description

The pitch.

# Trust layer: verifiable capsule receipts with CCF write-receipt anchoring (`capsule-emit-nanda`)

> cc @Skyrider3 @dhve — reopening the trust-layer work from #54 → #177, rebuilt
> on the CCF-native write-receipt format you pointed us toward. Grateful for the
> patient reviews. Details on the structural changes below.

Re-opens the work from #54 → #177 (closed by @Skyrider3), rebuilt with a fundamentally
different anchoring architecture: instead of an on-trace hash chain (which is self-authored
evidence — the plugin controls the seal events), the committed fixtures are **CCF / Azure
Confidential Ledger write receipts** obtained out-of-band from an independent transparency
service. The graded run replays these offline — zero network, filesystem, environment, or
clock access in the verdict path.

## Every rejection point from #177, addressed

**1. "The plugin is never installed/registered in CI."**
`capsule-emit-nanda` is a declared root dependency; plain `uv sync` installs and registers
it. `uv run nest run scenarios/receipt_reputation_capsule.yaml` runs end-to-end.

**2. "The adversarial validator never runs."**
`validate_receipt_reputation_anchored` is registered in `VALIDATORS` under a new
`receipt_reputation_capsule` scenario type. Each signature-valid receipt observed on the
trace must have a matching pre-committed CCF write receipt that verifies offline against the
pinned service identity. Proven:
- Capsule scenario → **PASS** (all 29 receipts anchored, CCF write-receipt verified offline).
- `agent_receipts` baseline (no anchoring evidence) → **FAIL** (discrimination proven).
- Forged receipt, wrong-identity receipt, tampered claim → all **FAIL**.
- Stock `receipt_reputation` scenario **untouched** — validator scoped to its own type.

**3. "Pyright gate was excluded, not passed."**
All strict errors fixed; `uv run pyright` → **0 errors** (full repo, no excludes).

**4. "`anchor=True` default → live POST; nondeterministic trace."**
`anchor=False` in the graded run — no network. Trace is byte-identical across runs.

## Anchoring architecture (what changed from #177)

The gate no longer reads any file the plugin-under-test wrote during the graded run.
Instead, it replays **pre-committed CCF write receipts** that were obtained once, offline,
from an independent Azure Confidential Ledger (`https://aac.confidential-ledger.azure.com`),
and committed under `nest_plugins_reference/trust/ccf_receipts/`. Each receipt carries:
a `LedgerEntryV1` application claim (`contents` = the scenario receipt's JCS digest),
a Merkle inclusion proof to the ledger's tree head, and a node signature endorsed by the
pinned service identity. The verifier (`nest_core.ccf_receipt`) checks the full chain:
`contents == digest → claims_digest == SHA-256(claim) → Merkle fold → node cert endorsed
by pinned identity → ECDSA (prehashed SHA-256) over tree head`. Zero-claims receipts are
structurally rejected.

**What this means for the self-authored-evidence concern:** the graded run cannot produce
or forge these receipts — they must exist before the run starts, and they must be
obtainable only via the external ledger. A non-anchoring plugin produces none and fails.

## Honesty about the root-of-trust pin

The pinned certificate (`PINNED_ACL_SERVICE_IDENTITY_PEM` in `nest_core.ccf_receipt`) is
a self-signed `CN=CCF Service` cert — the same format any CCF instance (local or Azure)
produces. **We are not claiming it is cryptographically distinguishable from a local CCF
cert.** What we can provide:

- Azure CLI confirms it is a genuine managed resource: `az confidentialledger show --name AAC --resource-group asg-scitt`
- The Azure identity service returns the same cert independently: `curl https://identity.confidential-ledger.core.azure.com/ledgerIdentity/aac | python3 -c "import sys,json; print(json.load(sys.stdin)['ledgerTlsCertificate'][:50])"`
- Expected SHA-256 of PEM: `905da11bf6bfa02195d8db52e4d128bc2df128d32d54be74a5dc49c85504facf`
- Transaction range: `2.

…