Block-layout array literals with ranged cells crash the compiler

[thiremani]

Summary

A ranged cell inside a block-layout (multi-line) array literal aborts with an
internal compiler error. The inline equivalents of the same literals compile and
produce correct output, so this is specific to block layout.

Reproduce

1. No function call involved

t.spt

arr = [10 20 30]
i = 0:3
b = [
    [arr[i]]
]
"B: -b"

💥 internal compiler error: internal: ranged array access reached scalar lowering without an iterator loop

2. With a call

lib.pt

res = Pair(x)
    res = [x x]

t.spt

arr = [10 20 30]
i = 0:3
b = [
    [Pair(arr[i])]
]
"B: -b"

💥 internal compiler error: runtime error: index out of range [0] with length 0
	compiler/array_nd.go:64
	compiler/array_nd.go:63

The inline forms are correct

b = [[arr[i]]]          # B: [ \n 10 20 30 \n ]        correct
b = [[Sc(i)] [Sc(i)]]   # B: [ \n 0 2 4 \n 0 2 4 \n ]  correct
b = [Sc(i)]             # B: [0 2 4]                   correct

So the range driver, the collector, and the call specialization all work; only
block-layout cell lowering does not establish the iterator loop.

Note for whoever picks this up

compileArrayValuedCell (compiler/array_nd.go:64) indexes compileExpression(...)[0]
with no length check, which is what turns case 2 into a panic. Adding a nil-guard
there is not the fix. The recorded error at that point is
function Pair not found for argument types [I64], which is itself spurious —
Pair(I64) plainly exists and p = Pair(5) compiles fine. Surfacing it would accuse
correct user code instead of reporting the real problem. Case 1 shows the underlying
defect with no call involved at all: block-layout cells reach scalar lowering without
an iterator loop.

Scope

Pre-existing. Both cases reproduce identically on 9fca83a and on the current branch
tip, so this is not a regression from any recent PR.

[thiremani]

Review feedback identifies the root cause more precisely than this report does.

The early return in HandleArrayLiteralRanges (compiler/solver.go) correctly stops a
block literal from becoming a collector, but it also prevents traversal into nested
inline collectors. That explains why [[arr[i]]] works while the block form does not.

The proper fix is to visit and rewrite each block cell while keeping the outer block's
Ranges and CollectRanges empty. Then:

• [arr[i]] inside a block stays a valid materialized array-valued cell
• a directly expanding block cell such as a bare arr[i] stays invalid
• the scalar Pair(I64) specialization is registered naturally

This supersedes the "reaches scalar lowering without an iterator loop" framing above,
which was the symptom rather than the cause. The note about not adding a nil guard at
array_nd.go:64 still stands: it would surface a spurious "function not found" for
code where the function plainly exists.

Remaining a P2 follow-up so PR #65 does not grow further.