feat(evaluator): model the mesh so check can reference a coordinate-reading program

[zhen8838]

Why

check cannot establish a reference value for any program that reads its mesh
coordinate. The evaluator models a single mesh participant by design
(docs/spec/evaluator.md:225: Reshard "performs no cross-participant data
movement", Local "returns its operand's value for the single modelled
participant"), so m.w has no value:

m.w desugars to:  Arange((4,)) -> Reshard(S(0)) -> Local() -> Reshape(())
intended:         [0,1,2,3]       split by mesh    this unit -> (1,)  -> scalar u
today:            [0,1,2,3]       identity         identity  -> (4,)  -> crash

$ tilefoundry check <fixture>:Strided --inputs random --out output --fn nan_inf
tilefoundry check: error: shape '[]' is invalid for input of size 4

This blocks the ordinary way to split a long reduction over a worker axis
(b0 = t + m.w * BLK) — the only placement with enough parallel units for
long-context attention. tests/fixtures/placed/flash_split_k_decode.py:59
already has this shape.

What

Two facts worth recording before anyone picks this up.

The unsound set is exactly one condition. parser/pattern_nodes.py:2903 is
the only site that constructs Local, so reading the coordinate is the only
source of per-unit variation. When nothing varies per unit, every unit computes
the same value and today's identity reading coincides with the truth — that is
why Fixed-shaped programs pass. A static marking

unit_varying(e) = e is Local on a Split axis | any operand is unit_varying

measured over all of tests/fixtures/ — 54 functions, 814 Call nodes — marks
55 nodes (6.8%), all inside the two functions that read the coordinate.
Everything else is unaffected by whatever fix lands.

Neither JAX nor Shardy has a reference evaluator to copy. Shardy is
representation + propagation + SPMD partitioner; execution is delegated to the
backend. shard_map's reference semantics is
concatenate([f(blk) for blk in split(y)]) with per-device local shapes, and
that equation only holds for a collective-free body — ours has one
(Reshard S→B is an all-gather).

Contract

docs/spec/evaluator.md §6 has to change: today's three statements
(single participant / Reshard does not move data / Local is identity) are
what any fix replaces. Until then, check's answer for a mesh program is only
correct when no node reads the coordinate.

Risk

• Refusing this path is already going out (fix/failure-diagnostics), so the
  failure is diagnosable in the meantime; this issue is about computing it.
• docs/spec/evaluator.md does not say what TensorValue.data holds for a
  Partial value. Today Reshard P→B is identity, which is right under
  "data is already reduced" and wrong under "data is one unit's partial".
  No fixture produces it, but ir/hir/tensor/index_select.py:78 and
  visitor_registry/shard_propagate.py can. Settle this before implementing.
• Separately, typeinfer accepts an op reducing across a Split axis with no
  intervening Reshard (probe builds cleanly). The evaluator's answer there is
  right; the legality question is not this issue's.

[zhen8838]

Direction settled with the author: MeshScope region first, then a mesh-index
primitive — not an evaluator that reverse-engineers the coordinate out of
placement.

The precedent worth copying is Triton, not JAX/Shardy

Triton's interpreter (TRITON_INTERPRET=1) is exactly the per-unit loop:
GridExecutor iterates the grid in Python, calls set_grid_idx(x, y, z), and runs
the whole kernel body once per program id. tl.program_id(axis) is a one-line
handler over grid_idx[axis]. Programs merge through memory pointers
(create_masked_store → _interpreter.store(ptrs.data, ...)); there are no
value-level collectives.

That last line is the whole reason it stays simple, and it is where we differ:
our Reshard S→B is a value-level all-gather, so some node does need "every
unit's value at this point". The loop is not the hard part; that is.

Why the current encoding makes it worse than it needs to be

Triton:       program_id(0)                                    1 primitive node
TileFoundry:  Arange(4) -> Reshard(S(0)) -> Local -> Reshape(())   4 nodes

The coordinate is derived from placement, so the DSL needs no coordinate concept
and Local becomes the single choke point
(parser/pattern_nodes.py:2888-2904 is the only site that builds it). Three costs,
all of which we hit:

1. none of the four nodes carries a source span — being fixed separately on
   fix/failure-diagnostics;
2. the failure reads as a shape error (shape '[]' is invalid for input of size 4)
   rather than "I do not know which unit I am";
3. detecting "this program reads the coordinate" means sniffing for
   Local-on-Split instead of looking for the primitive.

The intended shape

1. Land MeshScope as a HIR region — docs/plans/mesh-scope-execution-domain/PLAN.md,
   not started as of 2026-08-30. It gives the execution domain a structural home;
   today with Mesh(...) evaporates in HIR and survives only as per-Expr metadata.
2. Add a mesh-index primitive Call (program_id-shaped) and drop the
   Arange -> Reshard -> Local -> Reshape encoding.

What that buys: the evaluator handler becomes return ctx.unit[axis]; the unit
binding belongs to the enclosing MeshScope rather than being threaded by data
dependence; the refusal condition becomes "this program uses the mesh index",
which is a fact about the program rather than an inference about layouts;
Local / Reshard stay identity outside the collective cases.

What it does not buy: per-unit evaluation and the S→B all-gather are still
required. The primitive removes the encoding's accidental complexity, not the
semantics'.

This makes mesh-scope-execution-domain a prerequisite for this issue rather
than merely adjacent to it — superseding the "not a dependency, just do not fly
both at once" reading recorded in docs/plans/check-on-real-models/PLAN.md D12.

[zhen8838]

The prerequisite named above is now open as #139 (execution domain as a HIR region, plus the mesh-index primitive). Question 1 there — global-logical vs per-device-local types inside the region — is the one that decides how much of this issue is left.

[zhen8838]

Correction to the comment above: #139 was opened by mistake and is closed. The execution-domain design is being worked out in the local plan under docs/plans/mesh-scope-execution-domain/; what this issue needs from it is unchanged — global-logical vs per-device-local types inside the region is the load-bearing question.