fix: diagnose ?(?T) tuple-payload mismatch instead of malformed IR (issue 0165)

In type position (T) is a 1-tuple (specs.md:843), so ?(?i64) is
optional(tuple(?i64)); assigning a bare ?i64 had coerceToType classify
.none and pass the value through, then optionalWrap built a corrupt
insertvalue that aborted the LLVM verifier. After coercing toward an
optional's child, verify the coerced type equals the child type
(stmt.zig decl-init + coerce.zig .optional_wrap); on mismatch emit a
located diagnostic (tuple-specific note only when the child is a tuple).
formatTypeName now renders tuples as (x: i64, y: i64).

Regressions: optionals/0911 (nested optional via alias, round-trip),
diagnostics/1195 (the mismatch diagnostic). Updated diagnostics/1101 +
protocols/0414 goldens for the improved tuple type-name rendering.
Verified by 3 adversarial reviews. Filed adjacent bug 0171 (?any child
not canonicalized).

examples/diagnostics/expected/1101-diagnostics-err-tuple-oob.stderr

@@ -1,4 +1,4 @@
-error: field '42' not found on type 'tuple'
+error: field '42' not found on type '(i64, i64)'
   --> examples/diagnostics/1101-diagnostics-err-tuple-oob.sx:6:15
    |
  6 |     return xx t.42;

examples/diagnostics/expected/1195-diagnostics-err-parenthesized-optional-tuple.exit

@@ -0,0 +1 @@
+1

examples/diagnostics/expected/1195-diagnostics-err-parenthesized-optional-tuple.stderr

@@ -0,0 +1,5 @@
+error: cannot assign a value of type '?i64' to optional '?(?i64)': its payload type is '(?i64)' (note: in type position '(T)' is a single-field tuple, not a grouping — write the inner optional without parentheses)
+  --> examples/diagnostics/1195-diagnostics-err-parenthesized-optional-tuple.sx:16:3
+   |
+16 |   outer : ?(?i64) = inner;
+   |   ^^^^^^^^^^^^^^^^^^^^^^^^

examples/diagnostics/expected/1195-diagnostics-err-parenthesized-optional-tuple.stdout

@@ -0,0 +1 @@
+