fix(parse): recognize a window function using a named window

[tiagolauer]

Fixes #301.

The bug

Query<DB, 'select sum(salary) over w from users window w as (order by id)'>
// { 'over w': number }[]

Expected { sum: number }[]. The value type comes out right by coincidence; the key is nonsense.

The fix

FindOverKeyword/SplitWindowExpression required a ( directly after over, so the named-window form was not recognized as a window expression and the entry fell through to the first-space bare-alias split — making over w the alias of sum(salary).

What follows OVER may now be a name instead of an inline definition, in which case it is consumed as the window reference and whatever comes after it is treated as the alias, exactly as the parenthesized form already does.

The [never] guard that came with it is the interesting part. FindOverKeyword resolves to never for an entry with no OVER at all, and never extends { expr: infer E extends string; rest: infer R extends string } passes with both infers falling back to their constraints — so with the paren no longer required, Rest came through as string and every column in the suite was read as a window function (308 errors across 42 files on the first run). Same [never] pattern ExtraSourcesAfterKeyword and ParseWithClause already carry.

Verification

tests/window.test-d.ts, three new cases, all red on master:

tests/window.test-d.ts(47,3): error TS2344: Type 'false' does not satisfy the constraint 'true'.
tests/window.test-d.ts(54,3): ...
tests/window.test-d.ts(61,3): ...

• over w unaliased (keyed sum), with an as total alias, and alongside a regular column

The four existing assertions (inline over (...), empty over (), aliased, alongside a column) stay pinned.

tsc --noEmit clean, 192 runtime tests pass, budget 192,572 (+86).