[sharadgaur]

Summary

A tuple element can be read by index after a column, col.1. That worked
for an unqualified column but not for a qualified one:

SELECT a.1 FROM t       -- parsed
SELECT t.a.1 FROM t     -- rejected: expected <ident>, but got <int>

The path parser consumed the dot after a and then required another
name. It now stops when a number follows the dot, and the existing index
operation reads .1.

Validation against ClickHouse

Checked with clickhouse local 26.2.1 using formatQuery. Each
formatted output was fed back to ClickHouse and parses.

SQL	ClickHouse	Before	After
SELECT t.a.1 FROM t	valid	rejects	accepts
SELECT db.t.a.1 FROM db.t	valid	rejects	accepts
SELECT t.a.1 + 1 FROM t, also in WHERE and ORDER BY	valid	rejects	accepts
SELECT f((t.a[1]).1, u.b.1) FROM t, u	valid	rejects	accepts
SELECT a.1 FROM t, (a[1]).1, a[1].1, tuple(1, 2).1	valid	accepts	accepts
SELECT t.a.b FROM t, t.a.:Int64	valid	accepts	accepts
SELECT t.a.1.:Int64 FROM t	syntax error	rejects	rejects

Changes

• One condition in the qualified-name loop of parseIdentOrFunction.
  The result is an IndexOperation over the Path, the same shape
  a.1 already produces over an Ident.

No AST, visitor, walk or formatter change.

Not in this PR

• A chained index, a.1.2 or t.a.1.2, is still rejected. ClickHouse
  parses it as (a.1).2. The lexer reads 1.2 as one number there.

Tests

• testdata/query/select_tuple_element_of_qualified_column.sql
• One rejected form added to TestParser_InvalidSyntax.
• No existing golden file changes.

make test passes. golangci-lint v1.53.3 (the CI version) reports nothing.