fix: optional-chain index opt?.xs[i] over array/ptr-array field (issue 0181)

opt?.xs[i] typed and lowered the index over the optional CONTAINER
(?[N]T); getElementType returned .unresolved, so index_get reached LLVM
with an unresolved element type and panicked. Mirroring the 0101
!-unwrap fix: add lowerOptionalChainIndex (optional_has_value -> some:
unwrap + index (index_gep+load for ?*[N]T, else index_get) +
optional_wrap; none: const_null; merge -> ?ElemType, element-optional
flattened). The typer + dispatch guard compute the element via
ptrToArrayElem(child) orelse getElementType(child), so value-arrays,
slices, many-pointers, AND pointer-to-array (?*[N]T) children resolve.
Null receivers short-circuit (no null deref).

Regression: examples/optionals/0915-optional-chain-array-field-index.sx.
Verified by 3 adversarial reviews, suite 794/0. Filed broader pre-existing
gap 0183 (indexing a non-indexable type panics instead of diagnosing).

src/ir/lower.zig

@@ -1982,6 +1982,7 @@ pub const Lowering = struct {
     pub const lowerNumericLimit = lower_expr.lowerNumericLimit;
     pub const lowerStructConstant = lower_expr.lowerStructConstant;
     pub const lowerOptionalChain = lower_expr.lowerOptionalChain;
+    pub const lowerOptionalChainIndex = lower_expr.lowerOptionalChainIndex;
     pub const vectorLaneIndex = lower_expr.vectorLaneIndex;
     pub const lowerFieldAccessOnType = lower_expr.lowerFieldAccessOnType;
     pub const lowerEnumLiteral = lower_expr.lowerEnumLiteral;