fix(parse): check the write target when nothing else does

[tiagolauer]

Fixes #271.

The bug

StrictQuery<DB, 'insert into ghosts (name) values ($1)'>  // Record<string, never>[] - no error
StrictQuery<DB, 'delete from ghosts'>                     // same
StrictQuery<DB, 'update ghosts set name = $1'>            // same

Add returning id and the expected QueryTypeError<'unknown table: ghosts'> appears. Add a WHERE to the DELETE and it also errors. So the hole sits exactly on the everyday INSERT — and a mistyped write target is about the most common write mistake there is. The README's limitations section says strict mode turns unknown tables into a QueryTypeError.

The fix

Table existence was only ever verified as a side effect of resolving some column, in RETURNING or in WHERE/ON. The EmptyRow path in InferRowWithChecked never resolved Sources against the schema at all.

It now does, in strict mode, reusing the AllKnownTables / FirstUnknownTable pair StarRow already reports with — so the message is identical to the one every other path produces. Loose mode still returns the empty row.

Verification

tests/unknown-write-target.test-d.ts, ten cases. Four red on master:

tests/unknown-write-target.test-d.ts(19,3): error TS2344: Type 'false' does not satisfy the constraint 'true'.
tests/unknown-write-target.test-d.ts(23,3): ... (27,3), (31,3)

• unknown INSERT / DELETE / UPDATE targets, through StrictRow and StrictQuery
• the RETURNING form that already reported it still does

Controls: a real target with no RETURNING and no WHERE still projects nothing (all three write shapes, plus update ... from orders), and loose mode is unchanged.

tsc --noEmit clean, 192 runtime tests pass, budget 193,122 (+636).