Monomorphize associated type aliases on array impl blocks

Follow-up to #143.

PR #143 added `ImplItem::Type` (associated type aliases) monomorphization for generic impls on **structs**, but the **array-impl** path is a no-op.

In `crates/wgsl-rs-macros/src/monomorphize.rs` the array branch has:

```rust
crate::parse::ImplItem::Type(_) => {
// Associated type aliases on array impls are not yet
// monomorphized — they're rare and would need the same
// alias emission logic as struct impls.
}
```

So a module like:

```wgsl
impl [T; 4] {
type Array = [T; 4];
fn len() -> u32 { 4 }
}
```

monomorphizes `len` but silently drops `type Array`. No `alias array_f32_4_Array = array;` is emitted, so any `Type::AssocType` resolving to `[f32; 4]::Array` fails to find a WGSL `alias` at render time.

**Fix:** mirror the struct branch — substitute type params in `t.ty`, build a synthetic `ItemImpl` whose `self_ty` is the concrete array type, push the `ImplItem::Type` into `self.generated`. `mangle_type` for arrays already exists (`mangle(&["array", &elem, &len])`), so the alias name falls out naturally. ~15 lines.

No silent corruption today — produces *no* code for the alias, and the user gets a clear render-time error. Enhancement, not a bug fix.

Start in crates/wgsl-rs-macros/src/monomorphize.rs and compare the array branch for ImplItem::Type with the existing struct branch. Substitute type parameters in t.ty, create the concrete array ItemImpl, and push the associated type into self.generated. Done means a generic array impl emits an alias such as array_f32_4_Array and associated-type resolution succeeds at render time.

Written by the indexing model from the issue text.