fix: support bracket index in @cast expressions, to enable type narrowing for array element access

[EfveZombie]

Problem

@cast expressions with bracket index access (e.g., ---@cast addresses[1] -nil) were not working correctly. Two issues existed:

1. Lexer/Parser did not support [] in @cast expressions

The doc lexer's lex_cast_expr state did not recognize [, ], or integer literals, causing ---@cast addresses[1] -nil to be incorrectly parsed. This corrupted the type inference for addresses, leading to a spurious Undefined field [1] warning.

2. Parsed IndexExpr had wrong AST structure

After fixing the parser, the TkInt token inside [1] was placed as a bare token in the IndexExpr node. However, LuaIndexExpr::get_index_key() expects a child Node (like LuaLiteralExpr), not a bare token. This caused:

• get_index_key() → None
• get_access_path() → None
• get_index_expr_var_ref_id() → None
• The cast's type narrowing silently failed to take effect
• addresses[1] remained string|nil instead of being narrowed to string, causing a spurious param-type-mismatch warning

Fix

1. Lexer (lua_doc_lexer.rs): Added support for [, ], and digit literals in lex_cast_expr
2. Parser (tag.rs): In parse_cast_expr, wrap TkInt/TkString tokens inside [] in a LiteralExpr node, making the doc IndexExpr structure consistent with Lua code IndexExpr

Tests

• Added test_array_index_with_cast in undefined_field_test.rs
• Added test_cast_bracket_index_narrows_type in param_type_check_test.rs to verify the narrowing actually works
• All 326 diagnostic tests pass

[gemini-code-assist]

Code Review

This pull request introduces support for bracket indexing in @cast expressions, enabling type narrowing for array elements (e.g., ---@cast addresses[1] -nil). The changes include lexer updates to recognize brackets and integer literals, and parser modifications to handle multi-level field access using both dot and bracket notation. Comprehensive tests were added to verify diagnostic behavior for parameter type mismatches and undefined fields. A review comment identifies that TkName tokens used within brackets should be wrapped in a NameExpr node to ensure the index key is correctly retrieved by the analysis engine, similar to how literals are handled.

[xuhuanzy]

This shouldn’t be handled this way; I’ve decided to implement it myself.