Phase 7: Add RL-Kernel CI, benchmark matrix, and release rules

[inaniloquentee]

Background

Split from #6 Phase 7: CI, Benchmarks, and Release Rules.

This issue owns the release-quality test and reporting matrix for the RL-Kernel integration. Earlier phases add controls, metadata, audit, operator comparison, distributed contracts, and profiling; this issue turns those pieces into repeatable CI/benchmark gates and publication rules.

Scope

• Add a CI matrix structure for RL-Kernel integration coverage, split by unit, CPU reference, GPU operator, distributed contract, and benchmark jobs.
• Add or formalize CPU tests for diagnostic math, metadata validation, fallback decisions, report serialization, and A0-A5 report slices.
• Add GPU operator test hooks for supported RL-Kernel backends without making RL-Kernel mandatory for native vime CI.
• Add distributed test hooks for TP/SP/CP contracts, with skip/xfail behavior based on hardware availability and backend descriptors.
• Add batch-invariance CI coverage for same-sample replay across batch size, padding/packing, active-mask density, dynamic sampling, and microbatch partitioning.
• Add named A0-A5 grid slices using the same report/result path as local audit runs.
• Add a scheduled benchmark matrix for representative vime workloads.
• Add a report template that separates operator-level, actor-window, and full-step claims.
• Define release rules for speedup claims and consistency claims, including audit, tolerance-based strict, and bitwise strict wording.

Non-Goals

• Do not add new operator implementations here.
• Do not duplicate Phase 6 profiling instrumentation or target selection from Phase 6: Add profiling-guided fast-path expansion telemetry #35.
• Do not duplicate Phase 3 replay/result-cube implementation from Phase 3: Build consistency audit harness and replay diagnostics #29.
• Do not duplicate Phase 4/5 operator contract implementations from Phase 4: Add single-card operator comparisons and drift attribution #30/Phase 5: Add distributed operator contracts and A0-A5 profiles #31.
• Do not make RL-Kernel mandatory for native vime users or default CI.
• Do not publish full-step speedup claims from operator-only benchmarks.

Acceptance Criteria

• CI can run native vime tests with RL-Kernel unavailable and still verify structured fallback behavior.
• CPU-only jobs cover diagnostic math, metadata validation, provenance comparison, and report serialization.
• GPU jobs are capability-gated and report skipped/unsupported cases explicitly rather than silently passing strict claims.
• Distributed jobs cover TP/SP/CP contract surfaces when enough GPUs are available.
• Batch-invariance and A0-A5 grid slices use the same result/report path as local audit runs.
• Benchmark reports identify model/workload, hardware, world sizes, dtype, backend IDs, contract IDs, warmup/measurement windows, and runtime/build fingerprints.
• Release templates separate operator-level, actor-window, and full-step metrics and state whether consistency is audit, tolerance-based strict, or bitwise strict.

Hardware / Execution Notes

• Most CI/report plumbing can be developed and reviewed on CPU or a single-card machine.
• GPU operator CI needs at least one CUDA GPU and an installed backend for backend-specific claims; otherwise it should report unsupported/skipped capability-gated cases.
• Distributed TP/SP/CP CI needs multiple GPUs, with 2 GPUs enough for minimal TP/collective smoke tests and 4-8 GPUs preferred for representative distributed contract coverage.
• Scheduled full-step benchmarks need the target training/rollout cluster configuration; Blackwell/B-card hardware is only required for Blackwell-specific release claims.

Dependencies

• Roadmap: RL-Kernel integration roadmap for vime #6.
• Phase 3 audit harness: Phase 3: Build consistency audit harness and replay diagnostics #29.
• Phase 4 single-card operator attribution: Phase 4: Add single-card operator comparisons and drift attribution #30.
• Phase 5 distributed contracts: Phase 5: Add distributed operator contracts and A0-A5 profiles #31.
• Phase 6 profiling/telemetry: Phase 6: Add profiling-guided fast-path expansion telemetry #35.
• Blackwell experiment consumer: [Experiment] Build Blackwell train-inference mismatch baseline for VIME post-training #24.