feat: parenthesized type grouping — (T) groups, (T,) is a 1-tuple (issue 0177)

In type position, parentheses now mirror value position: (T) (a single
unnamed element, no trailing comma) is a GROUPING that resolves to the
inner type; (T,) is a 1-tuple; (A, B) a 2-tuple; named (x: T) and spread
(..Ts) stay tuples; (...) -> R stays a function type. This lets a
closure/optional/function type be parenthesized for readability without
silently becoming a 1-tuple:
  [1](Closure(i64,i64) -> i64)   // array of closures (issue 0177) -> 7
  ?(?i64)                        // genuine nested optional (issue 0165 intent)

Parser: src/parser.zig returns the inner node for a single unnamed
non-spread no-trailing-comma parenthesized type. formatTypeName (both
generic.zig diagnostics + types.zig reflection) now render a 1-tuple as
(T,) so the spelling is unambiguous and diagnostics are self-consistent.
The 0165 coerce/stmt note reworded accordingly.

specs.md §Type Syntax updated; basic/0036 wrap return -> (i64,); obsolete
diagnostic 1195 removed (?(?i64) now compiles); regression
examples/types/0201-types-parenthesized-type-grouping.sx added; 0414 .ir
golden regenerated for the (T,) rendering. Resolves 0177; updates
0165/0170. Verified by 3 adversarial reviews; suite 792/0.

issues/0170-closure-optional-layout-truncated.md

@@ -16,6 +16,12 @@
 > `examples/closures/0311-closures-optional-closure.sx`. (Adjacent pre-existing
 > bug found + filed: 0177 — array-element closure direct call `fns[i](args)`
 > crashes.)
+>
+> **UPDATE (grouping):** with parenthesized-type grouping now in place,
+> `?(() -> void)` parses as optional-of-(bare function pointer) `() -> void`,
+> not a tuple-optional; assigning a closure literal to it correctly diagnoses the
+> closure-vs-bare-fnptr mismatch (use `?Closure() -> void`). The `g!()`
+> call-through fix here is unchanged and still correct for `?Closure(...)`.
 
 ## Symptom