fix(parse): resolve correlated subqueries in strict mode

[tiagolauer]

Fixes #273.

The bug

StrictQuery<DB, 'select (select count(*) from posts where posts.user_id = users.id) as post_count from users'>
// QueryTypeError<'unknown alias: users'>[]

That is the README's own scalar-subquery example. The lateral form was worse, because the inner error object replaced the derived row and the surfaced message pointed at the wrong thing:

StrictQuery<DB, 'select u.name, p.top_id from users u join lateral (select max(id) as top_id from posts where posts.user_id = u.id) p on true'>
// QueryTypeError<'unknown column: top_id'>[]

Not in the documented limitations — and CONTRIBUTING.md:68 claimed the README documented it, which it never did.

The fix

ScalarSubqueryType and BuildDerivedSourceMap ran the inner query through InferRowWith with only the inner query's own sources. Both now pass the enclosing FROM list down, and the WHERE scan consults it.

As a fallback, not as an addition to the scope. SQL resolves an inner name first and looks outward only when it is not there; merging the two lists would have invented an ambiguous column for every name the two levels share (select (select max(id) from posts) from users has an id on both sides). When the outer lookup fails too, the inner message is reported — the reference was meant for the inner query.

The second half of the issue is fixed too: a derived table that fails to type now surfaces its own error, instead of the outer query reporting the alias's columns as unknown. tests/where-strict.test-d.ts had that misdirection pinned (unknown column: id for a typo named naem); it now pins the real message.

Verification

tests/correlated-subquery.test-d.ts, ten cases. Five red on master, plus the updated lock:

tests/correlated-subquery.test-d.ts(17,3): error TS2344: Type 'false' does not satisfy the constraint 'true'.
tests/correlated-subquery.test-d.ts(27,3): ... (37,3), (47,3), (69,3)
tests/where-strict.test-d.ts(146,3): ...

• the README example, the same through an alias, a correlated LATERAL join, a correlated derived table
• a typo inside a correlated subquery still errors, and now names nope rather than the alias
• a standalone query is not given an outer scope it does not have: select ... where posts.user_id = u.id on its own is still unknown alias: u

Controls: uncorrelated scalar subquery and uncorrelated lateral join unchanged, loose mode unchanged.

tsc --noEmit clean, 192 runtime tests pass, budget 199,660 (+7,174, 100% of the ceiling — it stays under).