fix(types): join mismatched array/array branch merges as array<mixed> instead of bare mixed

[mirchaemanuel]

Fixes #587

Root cause

The type checker's branch-merge join (merge_match_arm_result_type in
src/types/checker/inference/expr/mod.rs, shared by match, ternary, and
?:/??) had no case for two array types with different element types. A
merge like match($argc) { 1 => [1, 2], default => ["a", "b"] } fell through
to bare Mixed, while the lowering side (wider_type_for_merge,
src/ir_lower/expr/mod.rs) keeps it an array. That divergence rejected
PHP-valid array uses of the merged value at compile time:

• passing it to a by-ref array parameter (expects Array(Mixed), got Mixed)
• in_array() / array_sum() (argument must be array)
• spread [...$r] (Spread operator requires an array), which additionally
  emitted a misleading follow-on Undefined variable: $s naming the
  assignment target

The homogeneous-arm versions of the same programs already compiled, because
identical arm types short-circuit before reaching the Mixed fallback.

Fix

Add a pure merge_array_branch_types helper mirroring the lowering-side
array/array and assoc/assoc rules: differing element (or key/value) types
widen elementwise to Mixed, so the merge stays array<mixed> /
array<mixed, mixed> and array operations type-check like they do for
homogeneous merges. It is consulted after the Void/nullable handling and
before object-union handling. Any pair that is not array/array or assoc/assoc —
including an indexed-vs-associative mix — returns None and falls through to
the existing Mixed handling, so scalar unions stay Mixed and object|null
merges stay nullable unions (no over-widening).

The misleading Undefined variable follow-on no longer fires for this issue
because the spread now type-checks. The underlying cascade (a failed-to-type
assignment RHS leaving its target unregistered) is a separate latent defect,
reproducible independently with <?php $x = 5; $s = [...$x]; echo count($s);,
and is left for a follow-up.

Note on runtime

This is a checker-only change and only aligns the static type. Runtime
correctness of heterogeneous array/array merges (the merge temp lowering /
segfault) is tracked by #549 and owned by PR #583; on current main a
heterogeneous merge may still fail in the EIR backend (e.g.
array_sum for PHP type Array(Str)). Accordingly, the regression tests assert
the type-check outcome only.

Test plan

• New unit tests (src/types/checker/inference/expr/mod.rs): elementwise
  widening for heterogeneous indexed and associative merges, shared-element
  preservation, and None for indexed-vs-assoc and non-array pairs.
• New checker-level e2e tests (tests/error_tests/type_system.rs): by-ref
  array param, array_sum/in_array, spread, and a ternary variant now
  type-check; a scalar (int vs string) merge still types as mixed and
  keeps rejecting array-only uses.
• cargo test -p elephc --lib merge_array_branch_types — 5 passed
• cargo test --test error_tests -- type_system narrowing — 86 passed
• cargo test --test codegen_tests -- match ternary — 183 passed
• cargo build clean, git diff --check clean

https://claude.ai/code/session_01HRvbcjPHa3kAojdCjNZL5L

[mirchaemanuel]

The misleading Undefined variable follow-on mentioned in the description is a separate error-recovery defect (a failed assignment RHS leaves the target unregistered) — reverified on current main with an independent repro and filed as #597.