distributed-systems-architect: private_commerce — four-layer cross-plugin composition with joint validators

Description

The pitch.

# [Hackathon] distributed-systems-architect: private_commerce — four-layer cross-plugin composition with joint validators

## Problem picked

None of the ten listed problems — this PR targets the gap they leave behind. Every merged hackathon plugin (gossip registry #24, streaming payments #21, hybrid_x25519 privacy #28, agent_receipts trust #26) was designed, tested, and validated **in isolation**. Nobody has asked what happens when they run **together**, and no validator in the repo can even express a cross-layer invariant. This PR is a **scenario + validator** submission per the charter ("a layer plugin *or* a scenario *or* a validator"): a `private_commerce` scenario that composes four merged plugins into one workflow, plus four joint validators that test emergent properties spanning layer boundaries.

## What it does

**Scenario (12 agents):** 5 buyers discover sellers through per-agent gossip registries (partition-honest — buyers 0-1 are partitioned away for the first 3000 ticks and must wait for the heal), open per-tick streaming payments, and send bids wrapped in hybrid X25519 + ChaCha20-Poly1305 envelopes. 4 honest sellers decrypt, deliver, and issue Ed25519 cross-signed purchase receipts; they also settle among themselves in a directed receipt cycle, forming the strongly-connected honest anchor that collusion severance needs. The adversary — `shill_seller-0` — looks legitimate on the registry, decrypts the bid, **drains the stream, never delivers**, and covers itself by wash-trading mutually co-signed fake receipts with `shill-0`. An auditor ingests receipts and negatives into the configured trust plugin and emits final scores.

**Joint validators** (registered as `VALIDATORS["private_commerce"]`):

| Validator | Layers spanned | Invariant |
|---|---|---|
| `commerce_discovery_precedes_bid` | registry × privacy | every encrypted bid is preceded by an honest gossip discovery of that seller |
| `commerce_bid_opacity` | privacy × transport | the known bid plaintext never appears in any `bid:` wire message (send / receive / **dropped**) |
| `commerce_undelivered_penalized` | payments × trust | a seller that drained a stream without delivering ends below the trust threshold — *despite* wash-traded receipts |
| `commerce_delivery_rewarded` | payments × trust | every fulfilment is backed by a payment stream, and fulfilling sellers score above threshold |

## Adversarial discrimination (one YAML line each)

The charter asks for validators the reference plugin cannot satisfy. Here each cross-layer check is pinned to the specific plugin that makes it pass:

- `privacy: hybrid_x25519 → noop`: bid envelopes become plaintext; `commerce_bid_opacity` **FAILS** (the other three still pass — the failure is surgically attributable).
- `trust: agent_receipts → score_average`: the shill's wash-traded receipts *raise* its running average to 0.75; `commerce_undelivered_penalized` **FAILS**. Under `agent_receipts` the isolated mutual co-signing pair is severed by the SCC analysis and the shill collapses to 0.0 — the composition passes.

Both discriminations are integration tests (`test_noop_privacy_fails_exactly_the_opacity_validator`, `test_score_average_trust_fails_exactly_the_penalty_validator`) that assert the *exact* verdict vector, not just "something failed."

## Design decisions & tradeoffs

- **Ground-truth sidecar (`bidmeta:`)**: opacity is unfalsifiable unless the validator knows the plaintext. Buyers broadcast a `bidmeta:` marker declaring what they encrypted; the validator then proves that string never rides the wire in a `bid:` message. In production this sidecar would not exist; in a test rig, making the invariant checkable is the point.
- **Marker broadcasts vs. functional sends**: markers (`discovered:`, `stream:*`, `fulfilled:`, `score:`) are broadcasts — recorded in the trace at *send* time, so a dropped delivery can never make the trace lie about what an agent did. Functional messages (bid, ack, receipt) get 3× send redu

…