feat: enforce uniqueItems and contains/minContains/maxContains in generated zod schemas

[vishkaty]

Follow-on to #34 (which closed #33). #34 restored the scalar, length, and items constraints that quicktype's typescript-zod target drops during generation. This restores the array set and cardinality constraints it also drops, using the same post-generation, object-scoped in-place injector - no regeneration against a moving base.

What it enforces

• uniqueItems -> appended .refine(). One field: Context.eligibility (CheckoutCreateRequestContextSchema, aliased by LookupRequestContextSchema).
• contains + minContains + maxContains -> appended .superRefine(). The top-level totals of the 8 checkout/cart/order response schemas MUST contain exactly one subtotal and one total entry.

Object-scoping is what keeps this correct: checkout totals (which $refs types/totals.json carrying the contains rules) is constrained, while fulfillment-option, line-item, and adjustment totals (inline arrays without those rules) are left untouched. A test covers that distinction explicitly.

Approach

Same mechanism as #34: constraints keyed by the parent object's full property-name set and applied only when the generated field's base kind agrees (the schema-drift guard), spliced onto the base z.array(...) call via the TS compiler API, wired idempotently into the existing generate_models.sh step. .refine()/.superRefine() are used for the two keywords zod has no native method for. zod is parse-only, so this is a safe, non-breaking addition.

Scope note: const

const was evaluated and has no injectable target in the generated 2026-04-08 schemas: the surviving occurrences are either unified away by quicktype (the message_* type consts collapse into a single MessageType enum), live on subtypes that are not generated (PaymentInstrument.type is correctly unconstrained at the base), rewritten by the compat projection, or sit inside an if/then conditional. The only load-bearing consts are the discriminators inside totals' contains clauses, which this PR enforces via the contains mechanism. So const is intentionally out of scope.

Verification

• npm run build (strict tsc) clean; npm test 24/24 pass (12 baseline from fix: enforce JSON Schema value constraints in generated zod schemas (#33) #34 + 12 new).
• Kill-test: reverting the injected spec_generated.ts fails exactly the 7 negative assertions (uniqueItems duplicate + checkout contains rejections + order cardinality); positives still pass. Non-vacuous.
• Injector is idempotent (re-run reports the fields already constrained, no double-injection).
• pre-commit (prettier v4.0.0-alpha.8, ShellCheck, codespell) clean.