Cerebras CSL compiler (cslc) and the CSL kernel language

The clearest example in this whole pass of a toolchain whose deployment constraints are architectural rather than incidental, and the compiler reference states them plainly rather than leaving them to be discovered on hardware. Two facts a reader should not have to learn the hard way: the target architecture must match the run system (wse2 vs wse3, no compatibility), and on hardware the fabric dimensions in the build must match the actual system, while any sufficiently large bounding box suffices for a simulator run. That asymmetry is why the simulator matters operationally - it is the only place the constraint is loose. THREE FIELDS ARE EMPTY ON PURPOSE: target_backends (no enum term for a wafer-scale engine), input_languages (no term for CSL, a language the repo's enum has never had to describe), and output_artifacts (no term for the ELF and build artifacts cslc actually emits; 'c' is not a faithful stand-in for a device binary, so it was left out rather than stretched). This is enum debt in the compiler schema, recorded honestly rather than papered over with a near-miss value. The same limitation is why the existing compilers/cutlass-cute record's 'cubin' is a reasonable approximation but these three are left empty. autotuning is false and this is a hardware consequence, not an omission: a compiler for a processor whose compiler statically schedules all data movement (see flops/alt-groq-compiler-constraints for the same argument on Groq, and engines/alt-groq-groqflow for the corresponding toolchain) has nothing to search over, because the schedule is decided rather than chosen. compile_time_seconds is null because no primary source publishes one.