feat(lang): block value requires no trailing ; (Rust-style)

A block's value is now its last statement ONLY when that statement is a
trailing expression with no `;`. A trailing `;` discards the value,
leaving the block void. This makes value-vs-statement explicit and lets
the compiler reject "this block was supposed to produce a value".

Compiler:
- Parser records `Block.produces_value` (last stmt is a no-`;` trailing
  expression) + `Block.discarded_semi` (the `;` that discarded a value),
  via `expectSemicolonAfter`. A trailing expression before `}` may now
  omit its `;` (previously a parse error). Match-arm and else-arm bodies
  are built value-producing regardless of the arm `;` (arms are exempt —
  the `;` is an arm terminator).
- Lowering: `lowerBlockValue` / the block-expr path / `inferExprType`
  respect `produces_value`. A value-position block that discards its value
  is a hard error (`lowerValueBody` for function bodies; the value-context
  `.block` path for if/else branches, `catch` bodies, value bindings,
  match arms). Pure-failable `-> !` bodies (value rides the error channel)
  and a value-if whose branches are void are handled without false errors.
- `defer`/`onfail` cleanup bodies lower as statements (void), so a
  trailing `;` there is fine.

Migration (behavior-preserving — output unchanged):
- stdlib + ~210 examples: dropped the trailing `;` on value-position last
  expressions. `format` now ends with an explicit `#insert "return
  result;"` (it relied on `#insert`-as-block-value, which `;` discards).
- Two `main :: () -> s32` examples that relied on the old silent
  default-return got an explicit trailing `0`.
- Rejection snapshots 0412 / 1013 regenerated (their quoted source lines
  lost a `;`); the diagnostics themselves are unchanged.

Docs/tests: specs.md "Block values" section; examples 0040 (rules) + 0041
(rejection); 3 parser unit tests. Filed issue 0066 (pre-existing
match-arm negated-literal phi-width quirk, surfaced not caused here).

Gates: zig build, zig build test, run_examples.sh -> 343 passed,
cross_compile.sh -> 7 passed (also refreshed its stale example names).

issues/0066-match-arm-negative-literal-phi-width.md

@@ -0,0 +1,60 @@
+# 0066 — match-as-value with a negated-literal arm builds a mismatched phi
+
+## Symptom
+
+A value-position `match` (the `if subject == { case ... }` sugar) returning a
+small integer type, where one arm is a **negated integer literal** (`-1`) and
+others are plain positive literals, fails LLVM verification:
+
+```
+LLVM verification failed: PHI node operands are not the same type as the result!
+  %bp = phi i64 [ 100, %match.arm.1 ], [ 10, %match.arm.2 ], [ -1, %match.arm.3 ]
+```
+
+The negated arm lowers its value at a different integer width (it emits an i32
+that is then sign-extended) than the positive-literal arms (i64), so the merge
+phi's operands disagree with its result type. Positive literals in every arm
+work; `if/else` with `-1` works. So it is specific to a **negated literal in a
+match arm value**.
+
+This is orthogonal to the trailing-`;` block-value rule — the repro uses the
+exempt `case …: expr;` arm form (unchanged by that migration) and reproduces
+with ordinary semicolon-terminated arms. Filed while writing the block-value
+regression example (0040); the example sidesteps it with positive arm values.
+
+## Reproduction
+
+```sx
+classify :: (n: s32) -> s32 {
+    if n == {
+        case 0: 100;
+        case 1: 10;
+        else:  -1;        // ← negated literal arm → phi width mismatch
+    }
+}
+main :: () -> s32 { classify(1) }
+```
+
+Expected: compiles, `classify(1)` returns 10. Actual: LLVM verification failure.
+
+Workaround: give the arm an explicitly-typed value (`else: { x : s32 = -1; x }`)
+or avoid the negation.
+
+## Investigation prompt
+
+Look at the match-as-value lowering in `src/ir/lower.zig` (`lowerMatch`, the
+`has_value_merge` path ~line 4500, and the arm `result_type` inference
+~line 11698). The arm value is lowered via `lowerBlockValue(arm.body)` then
+`coerceToType(v, v_ty, result_type)`. For a negated-literal arm the value's
+type comes out narrower than `result_type` (s64 here), and the coercion path
+that should widen it before the `br merge_bb, {v}` either runs against the wrong
+target or is skipped — so the phi gets an i32 operand under an i64 result. Make
+the arm value coerce to the merge's `result_type` consistently (mirror how the
+positive-literal arms are handled), or set `target_type = result_type` while
+lowering each arm body so the negate picks the right width. Verify with the
+repro above (expect exit 10) and add a regression example.
+
+## Status
+
+OPEN. Pre-existing match-value codegen quirk, surfaced (not caused) by the
+block-value work.