R1-072: Close R1 with compatibility audit

[1sgtpepper]

Checklist

• This fits the named release or area.
• This is small enough for one focused PR.
• Relevant checks are listed below.

Summary

• Current state: main has fixtures, goldens, release checks, and compatibility tests. It lacks the architecture corpus manifest, unified runner, machine-readable gate reports, benchmark budgets, and release-blocking conformance aggregation.
• Goal: Close R1 with compatibility audit through Corpus, benchmark, release-gate, performance, and scale evidence. Inputs are limited to manifested fixtures, expected artifacts, budgets, and selected commands; each fixture declares purpose, inputs, expected diagnostics/projections, and the contract/release gate it proves.

Affected Area

Release: R1 foundations
Area: tests

Dependencies:

• R1-071

Change

Required change:

• Input boundary: The change must accept only manifested fixtures, expected artifacts, budgets, and selected commands.
• Required output: The change must produce executable "R1 with compatibility audit" evidence that reaches the real path and fails under its negative control.
• Each fixture declares purpose, inputs, expected diagnostics/projections, and the contract/release gate it proves.
• Run the real selected-kernel path; broad mocks or direct calls that bypass the owning host do not count as release evidence.
• Exercise the real selected-kernel or named compatibility entry path; a direct unit call or broad mock that bypasses the owning seam is insufficient.
• Include a positive case, boundary/edge case, and negative control that fails when the guard or expected result is removed.

Include:

• The named fixture/assertions and one meaningful negative control only.
• The real selected-kernel or compatibility entry path named by R1/R2; no bypass-only mock proof.

Out of scope:

• Do not include unrelated cleanup, a new diagnostic rule, or a second architecture owner.
• Do not change CLI/API signatures, diagnostic code, severity, text, spans, ordering, schemas, baseline/suppression behavior, discovery, or file ordering unless this issue explicitly owns a versioned SchemaHost migration.

Likely files:

• tests/fixtures/
• tests/goldens/
• tools/corpus/
• benchmarks/
• .github/workflows/
• src/scieqlint/corpus/
• tests/corpus/

Test Notes

Acceptance checks:

• The fixture exercises the declared input boundary and verifies the required output.

• Assertions cover every requirement above, including one edge case and one meaningful negative control.

• The evidence reaches the named production/compatibility path and is deterministic under repeated or shuffled-equivalent input where applicable.

• Create or extend tests/test_release_gates.py and run python -m pytest tests/test_release_gates.py -q.

• Record the negative control: the exact assertion/guard whose deliberate removal makes the new test fail.

• Evidence: The manifest states purpose, expected artifact, and gate.

• Evidence: The real selected-kernel path produces deterministic pass/fail evidence.

Compatibility notes:
No public behavior change. Any public behavior drift needs a linked SchemaHost/versioned compatibility issue.