fix(codegen-ts): finish timestampMode:"date" — wire coercion, sqlite guard, view schemas

[dmealing]

Completes timestampMode: "date", which #281 left half-fixed. Found by a pre-publish review that verified by executing Zod rather than reading emitted text — the same gap that let #281 ship incomplete.

All three findings were Critical: each would have shipped date mode in a knowably broken state to four immutable registries.

Critical 1 — z.date() rejected every JSON wire value

The Insert/Update schemas validate raw request bodies (mountCrudRoutes → safeParse(req.body)), where timestamps arrive as ISO strings. z.date().safeParse("2026-08-08T10:00:00.000Z") is false, so date mode would have gone from "doesn't compile" to "compiles, then 400s every write" — and React form saves would have failed silently, the #227 pattern.

Now z.coerce.date() at all four sites: accepts wire ISO strings and datetime-local values, passes DB-driver Dates through unchanged, and .nullable() still short-circuits null so FR-035 present-null clearing is safe.

Critical 2 — sqlite/D1 + date mode emitted non-compiling code (regression from #281)

column-mapper's sqlite branch ignores timestampMode (bare text), but #281's ternaries keyed on the mode alone. Result: text("created_at").$defaultFn(() => new Date()) — TS2322 in the generated schema itself. That combination compiled before #281; the fix created the bug on the other dialect.

timestampMode now normalizes to "string" when dialect === "sqlite" at both choke points (normalizeConfig and makeRenderContext), so the option is a documented safe no-op there rather than a trap. D1 is covered — a D1 project's codegen dialect is sqlite.

Critical 3 — a fifth timestamp-Zod emitter was missed

zodTypeFor (via view-decl.ts) hardcoded z.string(), so a write-through entity or projection carrying a timestamp kept the original TS2322 cascade — the exact failure #281 set out to fix. Now mode-aware for TIMESTAMP only, and it threads the same opts object that types the view column, so the two cannot diverge again by construction.

field.date / field.time deliberately stay z.string() — verified against Drizzle: date() is string-typed and time() has no mode, so they genuinely aren't governed by timestampMode.

Also

• Value-object timestamps excluded from the mode (jsonb storage is always ISO string).
• A codegen-time warning when a @filterable timestamp meets date mode. Filtering such a column throws at request time in runtime-ts's filter parser; threading the mode through the runtime is genuinely invasive, so this surfaces it at build time instead of a production 500 — matching the migrate --dialect d1: the sqlite table-rebuild's PRAGMA foreign_keys OFF is a no-op on remote D1, so any parent-table rebuild fails with FOREIGN KEY constraint failed #226/migrate: no primary-key change kind, so moving a table's PK leaves it with none and every referencing FK fails #258 detect-at-generation precedent.

Testing — the gap that caused this

Every #281 test asserted on emitted source text; none executed a schema. This repo has a named precedent for that exact failure mode (0.20.6, z.string().ip()).

timestamp-mode-execution.test.ts writes real rendered output to a temp file, dynamically import()s it, and calls real safeParse on the real Zod object — including negative cases and the null-clearing path.

codegen-ts 1048 pass / 0 fail · golden diff zero (default string mode byte-identical).