feat(types): tagged-union enums — variant payloads + binding match + exhaustiveness (#56)

Extend `enum` from named int constants to a tagged union: a variant may
carry a payload (`enum Tile { Empty, Wall, Door(int), Portal(int, int) }`).
Such enums box to a heap record (an i32 tag at offset 0, then one 8-byte
slot per payload position); an all-bare enum keeps its zero-cost compile-
time-ordinal representation, byte-for-byte unchanged (every golden render
and the bootstrap fixpoint still hold).

- Parser: variant payload declarations, stored as N_PARAM kids on the
  variant node.
- Construction: by name — `Door(3)`, `Portal(x, y)`, bare `Empty` — resolved
  ahead of the function-call fallback and boxed with the payloads coerced to
  their declared types.
- match: destructures a tagged scrutinee, switching on the tag and binding
  each arm's payload names in a scoped local frame.
- Checking pass: a tagged `match` must be exhaustive (cover every variant or
  end in `_`), and constructor/pattern arities and binding forms are checked
  — all reported where the scrutinee's type is known.

Adds selfhost/tests/enums.ludic to the regression suite and documents the
feature in LANGUAGE.md and the enum/match pages.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/language/control/kw-match.md

@@ -11,6 +11,8 @@ order: 4
 
 A <code>match</code> replaces an `if`/`else` ladder that tests one value against several constants. It evaluates the subject once, then takes the first arm whose pattern matches; an arm lists one or more literal patterns separated by commas and points at a body with `=>`, and a lone `_` arm is the catch-all default. Patterns are compile-time constants — integers, char literals like `'w'`, or `enum` variants such as `Action.Guard` — which makes `match` ideal for dispatching on a key press, a tile code, or a mode. Each arm's body is a single statement or a `{ … }` block; matching lowers to plain branches, so it is as cheap as the `if` chain it replaces.
 
+When the subject is a **tagged-union enum** (an `enum` whose variants carry payloads), `match` also *destructures* it: an arm names a variant and binds its payload — `Door(n) => …`, `Portal(x, y) => …` — with `n`, `x`, `y` in scope for that arm's body. A tagged `match` must be **exhaustive**: it covers every variant or ends with a `_`, or the compiler rejects it, so a newly added variant flags every match that must handle it. See [enum](../structure/kw-enum) for the full picture.
+
 ```ludic
 program Steering {
   property Velocity { delta_x: int = 0, delta_y: int = 0 }

docs/language/structure/kw-enum.md

@@ -9,7 +9,32 @@ tip: A named set of integer constants — names for a magic-number space.
 order: 50
 ---
 
-An <code>enum</code> gives names to a set of related integer values so a magic-number space — a menu selection, a game mode, a machine state — reads as names instead of bare literals. Variants number themselves from `0` in declaration order, and you access one as `Name.Variant`, which is a compile-time `int` usable anywhere an int is: in `match` patterns, comparisons, and assignments. Ludic has no distinct enum runtime type yet — an enum value lives in an ordinary `int` or `var` and is saved with it — so `enum` is best understood as a readable naming layer over `int`.
+An <code>enum</code> gives names to a set of related integer values so a magic-number space — a menu selection, a game mode, a machine state — reads as names instead of bare literals. Variants number themselves from `0` in declaration order, and you access one as `Name.Variant`, which is a compile-time `int` usable anywhere an int is: in `match` patterns, comparisons, and assignments. When every variant is a bare name, an enum value lives in an ordinary `int` or `var` and is saved with it, so a plain `enum` is best understood as a zero-cost naming layer over `int`.
+
+## Tagged unions — variants with payloads
+
+A variant may also carry a **payload**, written as a parenthesized list of types after its name. Doing so turns the whole enum into a *tagged union*: a value is now one of several shapes, each with its own data, and the type remembers which.
+
+```ludic
+enum Tile { Empty, Wall, Door(int), Portal(int, int) }
+```
+
+You **construct** a variant by name — `Door(3)`, `Portal(x, y)`, or bare `Empty` for a payload-less one — and store or pass it as a value of the enum's type (`let t: Tile = Door(3)`). Each value is a small boxed record: a tag naming the variant, plus its payload.
+
+You take one apart with <code>match</code>, binding the payload names in each arm:
+
+```ludic
+function walk_cost(t: Tile) -> int {
+  match t {
+    Empty        => { return 1 }
+    Wall         => { return 0 }
+    Door(n)      => { return 10 + n }   # n is the door's int payload
+    Portal(x, y) => { return x + y }    # both fields bound in this arm
+  }
+}
+```
+
+A tagged `match` must be **exhaustive**: it either handles every variant or ends with a `_` catch-all. Leaving a variant out is a compile-time error (`match on Tile is not exhaustive: variant Door is unhandled`), so adding a new variant surfaces every site that must learn about it. Constructor and pattern arities are checked the same way. A plain (all-bare) enum keeps its compile-time-ordinal `Name.Variant` form and is unaffected.
 
 ```ludic
 program BattleMenu {