fix: make codegen output deterministic

[typedrat]

Regenerating from an unchanged Drizzle schema doesn't reliably produce an unchanged file. The worst case I found:

Move the WY entry to the top of the usStates object literal in db/drizzle/country.ts. It's a key reorder, in a file that declares no tables. Regenerate:

1717a1718        5955a5956        6935a6936
>         | "WY"  >    | "WY"     >    | "WY"
1742d1742        5980d5980        6960d6960
<         | "WY"  <    | "WY"     <    | "WY"

Three columns, three unrelated tables.

Custom types reach the output as text printed by the TypeScript checker, and TypeScript orders union members by internal type id — assigned when each literal type is first created anywhere in the program. So the printed order encodes the order the whole program got checked, and editing any file that mentions those literals can shuffle unions in tables that have nothing to do with it.

TS 6 has a stableTypeOrdering flag that would fix this at the source, but the checker doing this work is the one ts-morph bundles (5.9.2), not the project's typescript (6.0.3). I wired the option through and confirmed it reaches program.getCompilerOptions() and changes nothing. So ef0c08d sorts the members after printing instead. Same for intersections and object members; tuples are positional and left alone, and anything the parser chokes on passes through untouched.

Ordering

Nothing else was sorted either, so table, column and relationship key order was just the order things happened to be written in. 68a9815 adds a canonicalization pass over tables, columns, relationship owners and relation names, applied both when drizzleZeroConfig builds a schema and again on the way into codegen, so a hand-written schema canonicalizes too. It's idempotent.

Deliberately not sorted: primaryKey, the hops of a relationship, and the sourceField/destField arrays inside a hop, which pair up by position. normalizeClientSchema already sorts tables and columns before hashing the client schema, so those orders are provably invariant. primaryKey isn't — it feeds row-key strings, and primaryKey({columns: [b, a]}) is a real distinction.

Identifier allocation is the same problem. Names used to be handed out with a positional counter, so reordering the schema swapped userProfileTable and userProfileTable2 between two tables. 9bee7bd allocates from the whole key set at once: unique preferred name wins it outright, and when several keys want the same name they all take a suffix derived from their own key.

Bugs

Each has a test that fails on beta and passes here.

• 9bee7bd — table row types skipped the uniquifier entirely. user and users both emitted export type User; a table named schema emitted a second export type Schema. Both are invalid TypeScript. A table named row shadowed the imported Row.
• b5ff4f6 — writeValue matched customType, enableLegacyMutators and enableLegacyQueries by key name at any depth, and read the owning table and column from hard-coded keys[1]/keys[3]. A column named enableLegacyMutators had its entire definition replaced by a boolean.
• c3fd62d — getZeroSchemaDefsFromConfig looked the config up by base name. ts-morph turns that into a "path ends with" search, so a project with two drizzle-zero.config.ts files picked the wrong one and generated its import and typeof zeroSchema against an unrelated module.
• 853040a — three .find() lookups took whichever candidate came first, and the column lookup pushed a miss through a ! so an unresolvable column landed in the output as null. The two column lookups also disagreed with each other about duplicate column names, one taking the first declaration and one the last.
• dde5dd9 — the already-warned-about set was module scoped and never cleared, so only the first schema built in a process warned at all.
• d511d13 — camelcase case-maps with the host locale unless told not to, so an I in a key lowercases to a dotless ı under tr. V8 currently treats the undefined locale as root, which is why nobody's hit it, but ECMA-402 says host default.
• 57b772b — formatSchema had module loading, config resolution and formatting under one catch and reported anything that threw as "prettier not found". An unreadable .prettierrc quietly produced an unformatted file, and since the signature covers the formatted text, one whose signature didn't match any correct run.

The fixture diff

9e0d5ea regenerates both checked-in schemas and it's about 13,700 lines. It's all reordering — 6852 insertions against 6852 deletions, and sorting the lines of both versions leaves a delta of 36, every one of them a sorted union or object member. Probably not worth reading line by line.

Testing

735 unit tests, tsc --noEmit, oxlint, prettier --check and pnpm build are clean. Both integration fixtures typecheck against their consumers, and running the generator twice is byte-identical.

The Docker integration suite fails, 9 failed and 1 skipped. I ran it on unmodified beta and got the same result, so it's not from these changes. Everything times out in getNewZero(); db/test-utils.ts:1711 pins the server image to rocicorp/zero:1.7.0-canary.3 against a 1.8.0 client, which would explain it, but I haven't chased it down.

On ts-morph

Leaving the ^27.0.2 range alone. It's a runtime dependency and the bundled compiler decides how custom types resolve, so a transitive bump can move generated output with no input change — pinning it seems right in principle.

I tried 28 (bundles TS 6.0.2, has stableTypeOrdering). No API breakage and all 734 runtime tests pass, but it silently disables custom type resolution: every column falls back to a ZeroCustomType<…> alias, ~2000 extra lines in the integration fixture, and ReadonlyJSONValue stops resolving. It also puts 14 type errors in the existing suite, all of them CustomType<…> collapsing to unknown. Not TS 6 semantics — the project's own 6.0.3 handles those types fine on ts-morph 27 — and not the ts re-export, which I swapped for import * as ts from 'typescript' with no change. Looks like ts-morph 28's bundled declarations landing in the program break the conditional resolution, and any import type {Project} drags them in. Wanted a separate look, not this PR.