fix(mir): keep small runtime-indexed arrays in SSA

[niklebedenko]

Fixes #397.

Summary

• lower runtime extraction from fixed arrays of up to 16 elements as constant extractvalue plus value selects
• lower accesses to compiler-owned small local arrays as constant-address selections, including nested loads and stores
• retain ordinary dynamic GEP lowering for larger arrays and borrowed/external pointers
• add a bounded post-inline full-unroll pass (maximum trip count 16, threshold 512, no partial/runtime unrolling) before final O2 cleanup
• extend the GPU array_for_loop regression with nested aggregate runtime reads/writes and PTX local-memory assertions

The local-pointer restriction is intentional: speculatively touching all candidate elements is safe for compiler-owned local storage, but would change observable access behavior for shared or externally borrowed arrays.

Validation

• cargo test -p mir-lower -p mir-importer -p cuda-oxide-codegen
• cargo clippy -p mir-lower -p mir-importer -p cuda-oxide-codegen -- -D warnings
• cargo oxide run array_for_loop on RTX 3080
• downstream Impulse cross-ghost prism/tet GPU regression: runtime checks pass and strict PTX audit reports zero local-memory/stack warnings across five kernels

[nihalpasham]

Thanks for the PR. I think there's merit in examining this further. But as it stands, after looking at the full picture, I'm putting it on hold rather than merging.

The blocker is where the optimization lives, not whether it works:

• This bakes a code-growing transformation into the default compile pipeline for every kernel: the select-chain lowering is always-on, and the added loop-unroll + second O2 stage runs on all device code unconditionally.
• The side effects are global: kernels that never touch a runtime-indexed array pay for it — gemm_sol's PTX grows ~64%, and generated code becomes less predictable (a loop crossing the trip-count boundary silently flips its whole shape).

The general recommendation or guidelines for something like this is the three tiers for optimizations:

1. compiler defaults, which require broad applicability and have to clear a high bar (FMA-fusion class);
2. custom opts that live in a user's own project;
3. an oxide-owned opt registry; upstream, but off by default, where users pick what fits their workload.

This PR would qualify as a tier-3 opt. It's workload-specific (small runtime-indexed local arrays), and most importantly it doesn't clear the default bar: kernels that never touch the pattern pay for it. The implementation shape should follow the registry design too: a pliron pass (Pass/OpPass with the pass-manager and AnalysisManager), not lowering-embedded logic plus an unconditional change to the opt pipeline every kernel runs through.

Before landing anything, I think examining prior art like how nvcc/nvc++ handle small runtime-indexed local arrays today (their register-promotion and unroll policies) would be a good idea to see if it makes sense for us.

An additional note: the enabling fixes in the PR (dead-branch pruning, union over-alignment, uninhabited enums, array::Drain drop glue) are valuable independent of the pipeline question, and we'll likely split those out. The branch stays as repaired, labeled on-hold.

This addresses #397, but the issue stays open until the in-house version lands.