fix: check a barrier against its own participants, not always the block's

[vyncint]

Closes #133. Not a release — main carries this unreleased until 0.7.0 is cut.

The defect

A guard uniform within a block settles sync_threads and settles nothing wider. blockIdx and cluster::block_rank() are constant on every thread of a block and different on the next one, so

#[cluster_launch(2, 1, 1)]
pub fn only_rank_zero() {
    if cluster::block_rank() == 0 { cluster::cluster_sync(); }
}

is entered by one block of the cluster and skipped by the other, and the block that arrived waits forever. 0.6.x reported nothing at all — exit 0, no findings, zero opaque, even with --strict.

Reproducing it showed the report was narrower than the defect: grid::sync() under a blockIdx guard was equally silent. Not a cluster quirk — BlockUniform conflated block-uniformity with cluster- and grid-uniformity, and every barrier wider than a block inherited it.

The model

A second lattice beside lane uniformity. LaunchScope — Block ⊑ Cluster ⊑ Grid — records how far a value is actually constant; the dialect answers barrier_scope for how far each barrier reaches. A finding is raised when the guard's scope does not cover the barrier's.

The two axes stay separate on purpose. Uniformity answers a lane question and is what RC001 has always keyed on; nothing about divergent barriers changes. The scope axis speaks only where the lane axis has nothing to say — a lane-uniform branch over a barrier wider than a block.

Always warning, never promoted. The witness replays the lanes of one block; it cannot execute the second block this needs to show, so there is no concrete hang to confirm and confirmed would claim more than the evidence carries.

Precision — the harder half, and four of the six samples

Everything starts grid-constant and is narrowed only by what it reads:

kernel	verdict
cluster_sync() under block_rank()	RC001/warning
grid::sync() under blockIdx	RC001/warning
sync_threads() under blockIdx	clean — block guard, block barrier
grid::sync() under a kernel argument + blockDim	clean — the false positive most worth not having
cluster_sync() under cluster_idx()	clean — cluster guard, cluster barrier
cluster_sync() unguarded	clean

Also verified: n + blockDim_x() stays grid-constant (clean), n + blockIdx_x() does not (fires). Arithmetic carries scope correctly.

That required splitting what BlockUniform used to cover — blockDim/gridDim, nsmid, gridid, nwarpid, the launch environment registers and the cluster's shape are GridUniform; cluster_idx is ClusterUniform; smid, blockIdx, block_rank and the cluster coordinates stay BlockUniform. An interprocedural site keeps the narrow default, since the callee's scope is not knowable from the call.

Breaking, deliberately — hence the label

reconverge-core's Callee, BarrierSite and Analysis gain fields; CallKind gains ClusterUniform and GridUniform. SimtDialect::barrier_scope has a Block default, so an existing dialect keeps compiling and keeps the narrow answer — reporting a block barrier as cluster-wide would invent a hazard, and a dialect that says nothing should not be made to.

cargo-semver-checks agrees: major passes, minor fails (exit 100) — the 0.x break this is.

Deep test

just ci green · conformance green · mutation corpus precision 1.0, published table unchanged · MSRV 1.88 · surface gate vs upstream 26754ae5 + its self-test · witness count unchanged (a warning gets no witness) · fixtures re-recorded, lesson copies refreshed, one golden blessed for a line shift.

Docs: explain RC001 and the README flip from "this is a known gap" to what is now checked, and the README's remaining gap is restated honestly — value flow through memory is still unmodelled, so a per-block value read back from global memory can guard a cluster barrier unremarked.

Closes #133

Signed-off-by: Vyncint Ng 115854244+vyncint@users.noreply.github.com