Type-position parsing misreads Vec/Mat lookalike idents (e.g. `MyVec3f` -> vec3<f32>)

Found while reviewing #167 (expression position was fixed there in commit 2cca714); the type-position call sites still have the bug.

## Bug

`split_as_vec` / `split_as_mat` (crates/wgsl-rs-macros/src/parse.rs) use `split_once("Vec")` / `split_once("Mat")`, which match any ident **containing** the substring. The type-position parsing call sites (~parse.rs:1337 vec, ~1375 mat) therefore treat a user-defined type whose name merely contains a builtin alias as the builtin:

```rust
#[wgsl]
mod m {
struct MyVec3f;
fn f(x: MyVec3f) {} // parsed as vec3, not the user struct
}
```

Expected: `MyVec3f` resolves to the user struct (or an unsupported-type error); actual: silently parsed as `vec3`.

## Fix direction

Anchor recognition on the full identifier (e.g. `name.starts_with("Vec")` before calling the helper, or `strip_prefix` inside it), mirroring the fix to `builtin_wgsl_type_name` in #167 commit 2cca714, plus regression tests for type position.

Related: #167 (builtin constants; same helpers, fixed for expression position only).

Start in crates/wgsl-rs-macros/src/parse.rs at split_as_vec, split_as_mat, and the type-position call sites around lines 1337 and 1375; compare the identifier handling with the fix in #167 commit 2cca714. Add regression tests covering a user-defined MyVec3f type in type position, then run the relevant test suite and confirm it is not parsed as vec3.

Written by the indexing model from the issue text.