feat: comptime-cursor indexing of a named-tuple VALUE (GAP 1)

`tup[i]` where `i` folds to a compile-time integer (an `inline for`
cursor or a literal) now reads the i-th tuple field with its CONCRETE
type instead of failing with "cannot index a value of type '(…)'".

A tuple's elements are heterogeneous, so there is no runtime
element-indexing op — a comptime index lowers exactly like the `.N`
field-access path (a `structGet` of the i-th field). A genuinely
runtime index into a tuple value still falls through to the existing
"cannot index a value of type" error (no single element type). A
comptime index out of range gets a dedicated loud diagnostic.

This is the read side `race` needs: pull the i-th `*Task(T_i)` handle
out of a named-tuple param keeping its real type so field/method access
on it resolves.

Locked by examples/comptime/0652-comptime-tuple-cursor-index.sx.

examples/comptime/expected/0652-comptime-tuple-cursor-index.exit

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

examples/comptime/expected/0652-comptime-tuple-cursor-index.stderr

@@ -0,0 +1 @@
+

examples/comptime/expected/0652-comptime-tuple-cursor-index.stdout

@@ -0,0 +1,4 @@
+[0] = 7
+[1] = true
+[2] = 2.500000
+sum = 42