fix: literal element typing — typed-array null element, tuple coercion, positional var element (0173-0175)

0173: resolveArrayLiteralType gained no arm for [N]T/[]T heads, so a
([2]?i64).[...] head lost its ?i64 element type and a bare null reached
LLVM as const_null(.unresolved). Route structural heads through
resolveTypeWithBindings; validate an undefined element name in the head
via UnknownTypeChecker (semantic_diagnostics.zig) instead of a silent
empty-struct stub (no-silent-fallback).

0174: positional .{...} against a TUPLE target now coerces each element
to TupleInfo.fields[i] (was neither struct nor array, so uncoerced).

0175: a positional struct literal with a bare-variable element was
misclassified as a named shorthand (parser puns .{x} -> x=x), zeroing
the fields. has_names now consults the struct definition to reclassify a
punned non-field name as positional; positional coercion uses the
lowered value's real getRefType.

Regressions: optionals/0914, types/0199, types/0200, diagnostics/1196.
Verified by 4 adversarial reviews; suite 784/0. Filed adjacent bug 0176
(protocol-typed struct field method call aborts).

examples/diagnostics/1196-diagnostics-array-literal-head-unknown-type.sx

@@ -0,0 +1,21 @@
+// A typed array/slice literal head (`([N]T).[…]` / `([]T).[…]`) names its
+// element type exactly like a declaration annotation, so an UNDEFINED element
+// type name must be rejected with the same `unknown type '<name>'` diagnostic
+// the declaration path emits — NOT silently compiled.
+//
+// Regression (issues 0173–0175 adversarial review): the 0173 fix taught the
+// lowering's `resolveArrayLiteralType` to resolve a structural `[N]?T` head,
+// but for an UNDEFINED element name the resolver returned a forward-reference
+// empty-struct STUB instead of `.unresolved`. So `([2]?Undefined).[…]`
+// compiled silently (exit 0, "ok") with a wrong empty-struct element, where
+// `x: [2]?Undefined = ---` correctly errored. The unknown-type checker
+// (`semantic_diagnostics.zig` `walkBodyTypes`) now validates the array
+// literal's `type_expr` head through the same `checkTypeNodeForUnknown` walk a
+// declaration uses, so a genuinely-undeclared head element name is a loud,
+// located error (exit 1) — never a silent empty-struct compile or a raw panic.
+#import "modules/std.sx";
+
+main :: () {
+    arr := ([2]?Undefined).[ null, null ];
+    print("ok\n");
+}

examples/diagnostics/expected/1196-diagnostics-array-literal-head-unknown-type.exit

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

examples/diagnostics/expected/1196-diagnostics-array-literal-head-unknown-type.stderr

@@ -0,0 +1,5 @@
+error: unknown type 'Undefined'
+  --> examples/diagnostics/1196-diagnostics-array-literal-head-unknown-type.sx:19:17
+   |
+19 |     arr := ([2]?Undefined).[ null, null ];
+   |                 ^^^^^^^^^

examples/diagnostics/expected/1196-diagnostics-array-literal-head-unknown-type.stdout

@@ -0,0 +1 @@
+