feat: a CTE is a table you can join, and the plumbing is written once

[productdevbook]

Two pieces of the debt I listed as still open.

The CTE footgun

.with() returned the same builder type it was called on, so the CTE name was not a table anyone could join. The repository's own benchmark reached for the escape hatch to measure the shape at all:

.innerJoin("recent_posts" as never, ({ users, recent_posts }: any) => …)

An as never and an any standing where a type should be, in the file that publishes our numbers.

Now:

db.selectFrom("users")
  .with("recent_posts", recent)
  .innerJoin("recent_posts", ({ users, recent_posts }) => users.id.eq(recent_posts.authorId))

The CTE's row type reaches the join proxies, and a column it does not project is a compile error — pinned with @ts-expect-error. A bare SelectNode still works and widens that row to Record<string, unknown>, because there is nothing to infer from one.

The plumbing

Compile an AST this builder already produced, hand back a compiled query wired to run: written out nine times across five builders. compileNode and compiledFor do both, and the builders are 126 lines lighter.

The ninth copy is where the executor gets forgotten, which is exactly how MERGE came to have none (#196).

Honest accounting

Type escapes went 42 → 44. The CTE overload's implementation signature needs two, which is what writing an overload in TypeScript costs. I said I would reduce them and they went up by two; worth saying rather than rounding down.

pnpm test green: 3326 tests, lint clean, types clean, build clean.