chainaim-nisha : Outcome-Verified Settlement: per-tick payments gated by delivery, integrity, and conformance truly allowing for outcome versus tokens

Description

The pitch.

# Outcome-Verified Settlement: per-tick payments gated by delivery, integrity, and conformance truly allowing for outcome versus tokens

**Problem:** [03 — Streaming pay-per-second payments with mid-stream cancellation](docs/hackathon/problems/03-payments-streaming-x402.md)
**Layer:** `payments`
**Registered as:** `("payments", "outcome_verified_settlement")`
> **Naming note:** the spec's suggested key `("payments", "streaming")` is already held in
> `_BUILTINS` by merged PR #21 (and the spec's scenario filename,
> `scenarios/streaming_payments.yaml`, is likewise already occupied by that PR's shipped
> scenarios). Reusing it was impossible without either modifying that
> merged plugin (out of scope under the charter's additive-only rule) or silently
> clobbering its registration. So: a distinct key for a distinct invariant —
> `billed ≤ rate × verified units`, not `billed while the stream is open`. This plugin
> complements PR #21; it does not compete with it (the default gate reproduces its
> delivery-gated billing byte-for-byte).

**Persona:** `settlement-protocol-standards-eng`
**Branch:** `hackathon/settlement-protocol-standards-eng-outcome-verified-settlement`

## Visual explaination of PR Solution 

 https://incredible-baklava-420ffb.netlify.app/
 
## SKILL.md file 

  https://chainaim-outcome-verified-settlement-ext-production.up.railway.app/skill.md 

## Motivation

The spec's own frame for Problem 03 is *time-metered* billing: bill while the stream
is open, stop billing on close or partition. That's a real requirement and this PR
satisfies it. But time-metered billing only answers "did the clock tick" — it says
nothing about whether the metered unit was actually delivered, delivered intact, or
delivered *correct*. This PR adds a pluggable settlement **gate** so a tick can be
billed on any of three cumulative disciplines:

- the default gate reproduces today's delivery-gated billing byte-for-byte (a tick
  bills once the seller acks it), so it's a drop-in, not a rewrite;
- an opt-in integrity gate additionally requires the delivered bytes to match a
  declared checksum before a tick is billed, catching corruption in transit;
- an opt-in conformance gate additionally requires the delivered content to match
  the buyer's *committed* acceptance criterion for that specific unit — catching a
  seller that delivers a *different, real* unit's content with an honest checksum
  of what it actually sent. Integrity alone cannot see this: the checksum is
  honest, the content is just wrong.

The name `outcome_verified_settlement` is now literally backed by code: an L3 pass
means delivered AND intact AND conforming, not merely "the seller's own checksum
claim was self-consistent."

## The verification ladder

| Level | Gate | Verifies | Blind to | Status |
|---|---|---|---|---|
| L0 | none (tick-based) | clock advanced | everything | not shipped — the naive incumbent model this PR is *not* |
| L1 | `AckReceivedGate` (default) | something arrived | acked corrupt/wrong content | **shipped** |
| L2 | `ChecksumGate` (`gate: checksum`) | the *declared* bytes arrived intact | honestly-checksummed but wrong-unit content | **shipped** |
| L3 | `EvaluatorGate` (`gate: evaluator`, `criterion: reference_match`) | delivered content matches THIS unit's committed reference, on top of L1+L2 | subjective "is this good," anything beyond the committed criterion | **shipped** |

Each rung catches exactly one failure class the rung below is blind to.
`EvaluatorGate` composes `ChecksumGate` internally (`require_integrity=True`
default) and short-circuits on an integrity failure before the criterion ever runs.
The proof that L3 is not redundant with L2 — an honestly-checksummed reply to the
*wrong* unit that passes integrity and fails conformance — is isolated in
`test_outcome_verified_settlement_b5_checksum_passes_criterion_fails` and re-proven
through the real driver in
`test_outcome_ver

…