go: parse.sx — composite literals + 8 tests [nothing]

Adds Go composite literals:
  T{}                                  empty
  T{1, 2}                              positional
  T{X: 1, Y: 2}                        keyed
  []int{1, 2, 3}                       slice
  [3]int{1, 2, 3}                      array
  map[string]int{"a": 1}               map
  pkg.Point{1, 2}                      qualified
  []Point{Point{1,2}, Point{3,4}}      nested

AST: (list :composite TYPE-OR-EXPR ELEMS). Each element is an
expression or (list :kv KEY VALUE).

Two parser entry points feed the same AST:
  * gp-parse-primary picks up type-prefixed composites by seeing
    a literal-type starter ([, map, struct) and parsing a type
    first, then optionally a '{' body.
  * The postfix loop picks up ident-prefixed composites — after
    any base expression, '{' wraps it as a composite literal.

Known limitation flagged in plan: when statement parsing arrives,
the postfix '{' branch will misread `if cond { ... }` as a composite
literal. Standard fix: parser-mode flag suppressing composite-lit
disambiguation in control-flow expression positions. Added to plan.

Elided types in nested composites (`[][]int{{1,2},{3,4}}` with the
inner `{1,2}` typed implicitly) deferred.

parse 114/114, total 243/243.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

lib/go/scoreboard.json

@@ -1,10 +1,10 @@
 {
   "language": "go",
-  "total_pass": 235,
-  "total": 235,
+  "total_pass": 243,
+  "total": 243,
   "suites": [
     {"name":"lex","pass":129,"total":129,"status":"ok"},
-    {"name":"parse","pass":106,"total":106,"status":"ok"},
+    {"name":"parse","pass":114,"total":114,"status":"ok"},
     {"name":"types","pass":0,"total":0,"status":"pending"},
     {"name":"eval","pass":0,"total":0,"status":"pending"},
     {"name":"runtime","pass":0,"total":0,"status":"pending"},