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/optionals/expected/0914-optionals-typed-array-literal-null-element.exit

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

examples/optionals/expected/0914-optionals-typed-array-literal-null-element.stderr

@@ -0,0 +1 @@
+

examples/optionals/expected/0914-optionals-typed-array-literal-null-element.stdout

@@ -0,0 +1,5 @@
+7
+-1 -1 5
+1 2
+3
+1 2 3