Deeply nested type expressions overflow the parser stack

A type expression with many nested arrays makes `parse_forms` exhaust the thread stack and abort the process. The parser does not return an error. The same path is reachable through `ModuleParser` and `Assembler`.

`FragmentParser::parse_array_type` calls `parse_type_expr` for each array. The existing 256 level check runs later during type resolution, after the parser has built the full type.

This test reproduces the abort in `crates/assembly-syntax/src/parser/tests.rs`:

```rust
#[test]
fn rejects_deeply_nested_type_expression() {
let depth = 10_000;
let source = format!(
"type T = {}felt{}\n",
"[".repeat(depth),
"; 1]".repeat(depth),
);

let rejected = std::thread::Builder::new()
.stack_size(2 * 1024 * 1024)
.spawn(move || parse_forms(test_source_file(&source)).is_err())
.expect("failed to start parser thread")
.join()
.expect("parser thread panicked");

assert!(rejected, "deep type expression should return an error");
}
```

The parser should apply the existing type depth limit before the next recursive call.

The issue is in the parser for type expressions. Look at `crates/assembly-syntax/src/parser/mod.rs` for `parse_forms`, `parse_type_expr`, and `FragmentParser::parse_array_type`. The existing depth limit check is applied later during type resolution; you need to move it earlier to prevent stack overflow. The provided test in `crates/assembly-syntax/src/parser/tests.rs` shows how to reproduce the problem. Run the test to verify your fix prevents the abort and returns an error.

由索引模型根据 Issue 内容生成。