fix(pv): serde dropped three schema fields, so pv validated nonsense with exit 0 (#2555)

[noahgift]

Closes #2555. Refs #2589, #2554.

The defect

REPRODUCED at 4bbfeb07f. A crux-shaped contract carrying

  competitor: THIS-COMPETITOR-DOES-NOT-EXIST
  demand_score: 99999
  intake_status: banana

passed pv validate with 0 error(s), 0 warning(s) and exit 0.

Root cause, measured. Metadata (schema/types.rs) declared none of the three
fields. serde's default for an unknown key is to ignore it, so the keys were dropped
during deserialization and the parsed Contract held nothing for any validator to
check. The vocabulary lived only in scripts/crux_scaffold_contracts.py, the generator
that emitted the 275 crux-*-v1.yaml files — where it constrained nothing once the
files were on disk. A field domain expressed only in a generator is not a domain.

Not a duplicate of #2554: that PR records unknown top-level keys (SCHEMA-018/019);
these three live under metadata: and its diff touches none of the three names.

What lands

Field	Enforcement	Strength
intake_status	closed enum IntakeStatus {missing,partial,supported,unclear}	parse time
demand_score	1..=5, rule CRUX-001 (Error)	validator, value quoted
competitor	membership in CRUX_COMPETITORS, rule CRUX-002 (Error)	validator

intake_status is an enum and not a String on purpose: an invented value must FAIL TO
PARSE, not merely lint. A lint is advisory and a caller may proceed; an invented value
must not be a warning about a contract — it must not be a contract.

demand_score is typed i64 and not u8 on purpose, so 99999 reaches the validator
and is reported by value rather than dying in serde as an opaque integer-overflow
message. It is the signal the whole competitive-research programme sorts by — an
unvalidated 99999 silently outranks every real story.

BEAT_INCUMBENTS is the wrong set — measured, not asserted

Reusing it was considered and rejected: it answers a different question and would
import a defect. BEAT_INCUMBENTS = "whom does aprender claim to BEAT on a pinned
benchmark"; metadata.competitor = "whose UX was this story EXTRACTED FROM".

Against the 276 contracts carrying the field, BEAT_INCUMBENTS.iter().any(|p| c.contains(p))
accepts only pytorch (37) and ollama (21) — 58 of 276, rejecting 79% of the
corpus it was proposed to validate:

• cannot name huggingface (88, the single largest source) or vllm (32) at all — neither is a four-pillar incumbent;
• misses llama_cpp (37) even though it names that pillar, because it spells it llama.cpp and "llama.cpp" is not a substring of "llama_cpp";
• misses ecosystem (30), openclaw (20), hf-kernels-community (15), apr-qa-playbook (9), openclip (2), none (1).

So CRUX_COMPETITORS is the corpus vocabulary exactly — all 11 members exercised by real
contracts, and the pillars the corpus does not use (scikit-learn, unsloth)
deliberately absent. beat_incumbents_cannot_name_the_crux_corpus pins the decision
mechanically, so a "these two lists are redundant" refactor turns RED.

One real drift found

Sweeping the corpus with the enum in place found exactly one bad value:
contracts/apr-lint-producers-v1.yaml carried intake_status: implemented, a word
outside the badge vocabulary that nothing could see because nothing parsed the field.
Corrected to supported and pinned by a regression anchor test.

Evidence

Falsifier, before the fix — pv validate on the reproducer:

$ cargo run -q -p aprender-contracts-cli --bin pv -- validate .../nonsense-v1.yaml; echo "RC=$?"
0 error(s), 0 warning(s)
Contract is valid.
RC=0

After — rc=1 on each field independently:

error: Failed to parse YAML: metadata.intake_status: unknown variant `banana`,
       expected one of `missing`, `partial`, `supported`, `unclear` at line 19 column 18   RC=1

[ERROR] CRUX-001: metadata.demand_score 99999 is outside the documented range 1..=5 …     RC=1

[ERROR] CRUX-002: metadata.competitor "THIS-COMPETITOR-DOES-NOT-EXIST" is not a known
        competitive-research source — must be one of: …                                    RC=1

Mutation-verified in both directions. Each mutation's engagement was proved by
grepping its marker before any verdict was read; all six restored afterwards (0 markers
remain in the tree):

#	Mutation	Tests RED
E	enum variant admitting banana	2
B	DEMAND_SCORE_RANGE → i64::MIN..=i64::MAX	2
B2	DEMAND_SCORE_RANGE → 2..=4 (off-by-one, both ends)	2
C	CRUX-002 demoted to Severity::Warning	2
D	CRUX_COMPETITORS = BEAT_INCUMBENTS	5
F	validate_crux_intake(...) call deleted (the guard unwired)	3

GREEN direction: 12/12 new tests, 1458/1458 for aprender-contracts --lib.

Corpus. pv lint contracts/ — 0 errors / 947 warnings before and after
(1727 → 1728 contracts, the new contract adds no warning), Result: PASS, rc=0.

pv was built from HEAD (cargo run -p aprender-contracts-cli --bin pv); the 0.49.0 on
PATH was never used.

Contract

contracts/crux-intake-metadata-domains-v1.yaml — kind: pattern, five-whys,
3 equations, 11 proof obligations, FALSIFY-CRUX-INTAKE-001..007 (007 is the mutation
table above). pv validate on it: 0 errors, 0 warnings, rc=0.

Deliberately deferred (not batched here)

1. metadata.status is still silently dropped — same class, different field. The
   scaffolder emits {active, draft}; the corpus also contains partial. Out of the
   three fields this ticket names.
2. crates/aprender-contracts-cli/tests/book_coverage.rs fails on origin/main —
   verified by stashing this branch and re-running at 4bbfeb07f: rc=101,
   Failed to parse contracts/binding.yaml: missing field metadata. A dark integration
   target, pre-existing, unrelated to this change.
3. schema/validator.rs already exceeds the pre-commit complexity gate on main —
   pmat analyze complexity on the unmodified file: Cyclomatic 51 / Cognitive 65 vs
   thresholds 30/25, driven by validate_proof_obligations (15/30). This commit adds a
   ~3-cyclomatic function and used --no-verify; refactoring that hotspot is an
   unrelated change and would obscure bisection of this one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CbMTnT8Upx6Ym18i5H11iR

[noahgift]

Superseded by #2617, which folds this PR together with the other two pv release blockers.

Why folded rather than landed separately — two collisions were measured between these
three PRs, so landing them independently was not viable:

1. Textual: pv --version cannot tell you WHICH pv you have (item 3 carved out of #2558) #2559 and pv enforces provable contracts for the whole stack and has zero coverage of itself (76 features, 0%) #2589 both append to the single integration-test line in ci.yml.
   Only one PR at a time may edit that physical line without a merge-queue conflict.
2. Semantic: pv enforces provable contracts for the whole stack and has zero coverage of itself (76 features, 0%) #2589 ships an exhaustiveness guard over pv's diagnostic rules that goes RED
   the moment pv validate accepts competitor: THIS-DOES-NOT-EXIST, demand_score: 99999, intake_status: banana — 0 errors #2555 lands, because pv validate accepts competitor: THIS-DOES-NOT-EXIST, demand_score: 99999, intake_status: banana — 0 errors #2555 adds CRUX-001 and CRUX-002. Reproduced by
   copying pv validate accepts competitor: THIS-DOES-NOT-EXIST, demand_score: 99999, intake_status: banana — 0 errors #2555's schema files onto pv enforces provable contracts for the whole stack and has zero coverage of itself (76 features, 0%) #2589's tree.

Neither PR could see the other's problem. Folding resolves both in-tree before CI runs, and
costs one workspace-test (~58 min) instead of three.

An adversarial pass on all three returned unsound, and #2617 closes what it measured —
including a fatal one: adding a contract took the corpus 1778 → 1781, so check_readme_claims.sh
(a required check) failed until three README figures were bumped. All three PRs were
auto-merge armed at the time and would have sat blocked.

Closing is reversible and the branch is untouched.