…arity invariant (#1427)

Authors a new schema-kind contract that codifies the invariant uncovered by
the SHIP-007 v5 finding (PR #1426): for any model and prompt under greedy
decode (`--temperature 0.0`), `apr run` GPU output MUST match
`apr run --no-gpu` CPU output.

## Why now

The v5 falsifier showed:
- `apr run` GPU emits "ampiezza = 0.5\ndiametro = 10" (gibberish, 72.95s)
- `apr run --no-gpu` emits "2 + 2 equals 4." (correct, 9.81s)
Same model, same prompt, same temperature.

This regression slipped through because the existing parity_gate
(crates/aprender-serve/src/gguf/cuda/mod_parity_gate.rs) only fires for
`OwnedQuantizedModelCuda` construction (used by `apr parity` and
`apr run --force-gpu`). The default `apr run` path on .apr files goes
through `OwnedQuantizedModel::from_apr` → trueno manual graph (646
kernels), which has NO parity gate.

The code at `crates/aprender-serve/src/cli/apr_inference.rs:46` already
acknowledges: "Both AprF32ToGpuAdapter and forward_token_apr_q4k produce
garbage on GPU."

## Contract structure

- **kind**: schema (matches `apr-cli-trace-save-tensor-v1` pattern)
- **3 equations**: greedy_argmax_parity, cosine_parity, no_gpu_flag_honor
- **4 falsifiers**:
  - FALSIFY-CPU-GPU-001 (greedy argmax match) — PARTIAL, currently FALSIFIED in live data
  - FALSIFY-CPU-GPU-002 (cosine ≥ 0.99) — PARTIAL, apr parity reports cos=-0.005
  - FALSIFY-CPU-GPU-003 (parity gate enforced at apr run init) — PARTIAL, gap in trueno path
  - FALSIFY-CPU-GPU-004 (--no-gpu honored) — FUNCTIONAL, verified empirically
- **4 proof obligations**: invariant + completeness + liveness gates

## Five Whys

1. Why this contract? To codify a regression class so it can never slip
   through silently again.
2. Why didn't existing apr-gpu-parity-consistency-v1 cover it? That
   contract is about CLI scope-clarity (apr parity command output messages),
   not about runtime output correctness gates in apr run.
3. Why a new contract instead of extending apr-vs-gguf-forward-parity-v1?
   That one is about APR vs GGUF format parity (different concern).
4. Why PARTIAL on 3 of 4 falsifiers? FALSIFY-CPU-GPU-001/002/003 are all
   currently FALSIFIED in live data — the gate doesn't exist for the .apr
   trueno graph path. They're algorithm-bound to existing parity_gate code
   but functional discharge requires the implementation to extend coverage.
5. Why FUNCTIONAL on 004? Live tested 2026-05-03: --no-gpu produces correct
   "2 + 2 equals 4." with no [trueno#243] or [PMAT-082] log lines.

## Implementation follow-up (separate PR)

Extend mod_parity_gate.rs OR the OwnedQuantizedModel::from_apr loader path
to call parity_gate during the trueno graph init. The pattern is already
proven in mod.rs:268-279 (with SKIP_PARITY_GATE=1 escape hatch).

`pv validate contracts/apr-cpu-vs-gpu-output-parity-v1.yaml` returns
0 errors / 0 warnings.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>