compiler-API: welded structs by reflection + memory-order validation

Replace the explored byte-layout-override engine (offset-ordered LLVM structs /
weld plans / byte-blobs — all unnecessary) with a much simpler design: a welded
`struct abi(.zig) extern compiler { … }` is a bodied header declaring its fields
in the bound compiler type's MEMORY order. The compiler reflects the real Zig
type (field names via @typeInfo, offsets via @offsetOf, size via @sizeOf —
nothing hand-maintained) and validates the header matches, with loud diagnostics.

On pass it is an ordinary struct whose natural layout already equals the Zig
layout — no reorder, no padding, no index/remap tables, no special LLVM path — so
@ptrCast'ing it to the compiler's own type and dereferencing is byte-identical.
When types.zig shifts, the header stops matching and the developer gets a specific
message to fix it.

- compiler_lib.zig: weldStruct reflects field names and bakes bound_types fields
  in ascending-offset (memory) order; deleted computeWeldPlan/WeldPlan/WeldElement.
- nominal.zig validateWeldedStruct: precise diagnostics — field-not-found,
  wrong-field-order (+ expected memory order), type-layout (size) mismatch,
  total-size mismatch.
- Examples: 0627 (StructInfo in memory order, byte-identical, usable),
  1186 (source-order StructInfo -> wrong-field-order diagnostic); 1183 refreshed.
- Design doc + checkpoint updated.

design/comptime-compiler-api.md

@@ -93,6 +93,19 @@ build error — the sx side is a header checked against the implementation). Bec
 the same compiler builds both, they're guaranteed identical, and a `types.zig`
 change re-bakes the offsets on the next build — both sides move together.
 
+> **Implementation note (how it's exact, concretely).** No layout-override engine
+> is needed. The sx header DECLARES its fields in the compiler type's **memory
+> order** (Zig may reorder a struct from source order). The compiler REFLECTS the
+> bound Zig type — field names from `@typeInfo`, offsets from `@offsetOf`, size
+> from `@sizeOf`, nothing hand-maintained — and VALIDATES the header matches that
+> memory order, with loud diagnostics on drift (*field not found*, *wrong field
+> order* + the expected order, *type/layout size mismatch*). On pass the sx
+> struct's NATURAL layout already equals the Zig layout, so it is an ordinary
+> struct — no reorder, no padding tricks, no index/remap tables, no special LLVM
+> path — and `@ptrCast`ing it to the compiler's own type and dereferencing is
+> byte-identical. When `types.zig` shifts, the header stops matching and the
+> developer gets a specific message to fix it.
+
 This is what C-ABI `extern` can't do: it copies Zig's REAL layout, so Zig slices
 (`{ptr,len}`), field reordering, and `union(enum)` tag placement all "just work" —
 no slice→ptr+len surgery on `types.zig`, no version fragility.