feat(codegen): wire condition arg through ORM query builder for findMany/findFirst

[pyramation]

feat(codegen): wire condition arg through ORM query builder + vector/pgvector support

Summary

Two layered changes:

1. Vector/pgvector codegen support (base):

• Maps Vector scalar → number[] in TypeScript, adds VectorFilter (equality/distinct operators)
• Merges plugin-injected fields into condition types (e.g., embeddingNearby from VectorSearchPlugin)
• Merges plugin-injected orderBy values (e.g., EMBEDDING_DISTANCE_ASC/DESC)
• Discovers transitive types referenced by plugin-injected fields (e.g., VectorMetric enum inside VectorNearbyInput)
• Broadens generateCustomInputTypes to follow all non-scalar types in the registry, not just *Input types

2. Condition arg wiring through ORM layer (new):

• Adds TCondition generic parameter to FindManyArgs and FindFirstArgs interfaces (both template and ORM copies)
• Adds conditionTypeName parameter and addVariable() call in buildFindManyDocument / buildFindFirstDocument
• Wires ${TypeName}Condition into model-generator: imports, generic type params, body arg forwarding, and document builder calls
• Makes VariableSpec.typeName optional with a !spec.typeName guard so condition is cleanly skipped when not provided

Files changed: scalars.ts, input-types-generator.ts, select-types.ts (×2), query-builder.ts, model-generator.ts, plus tests and snapshots.

Updates since last revision

• Added explanatory comments in scalars.ts and input-types-generator.ts documenting why VectorFilter exists: similarity search uses condition types (embeddingNearby), not filters, but postgraphile-plugin-connection-filter may still auto-generate a filter for vector columns. Without the Vector → VectorFilter mapping, those fields would be silently omitted from the generated SDK. The filter's equality/distinct operators are rarely useful for embeddings, but the mapping ensures type-correctness if the filter type is present in the schema.

Review & Testing Checklist for Human

• VariableSpec.typeName made optional (query-builder.ts:825): Changed from typeName: string to typeName?: string. The addVariable guard prevents runtime errors, but verify no other callers depend on the required type to enforce correctness at compile time.
• Condition variable ordering is inconsistent: In buildFindManyDocument, condition is added before where. In buildFindFirstDocument, condition is added after where. GraphQL doesn't care about variable order, but confirm this inconsistency is intentional or harmless.
• ${typeName}Condition naming convention is hardcoded in model-generator.ts:178. Verify this matches what PostGraphile actually generates for all table types in your schemas.
• Broadened transitive type resolution in generateCustomInputTypes: Now follows all non-scalar types in the registry (previously only *Input types). Confirm this doesn't pull in unintended types.
• End-to-end test plan: Run codegen against a real schema with pgvector/BM25 condition types. Verify the generated ORM client accepts condition args and produces valid GraphQL queries with $condition variables. The unit tests verify generated code strings but not runtime behavior.

Notes

• Clean reimplementation of condition arg support originally prototyped by another agent on codegen/vectors-v2, with consistent code style and comprehensive tests
• 3 new unit tests (model-generator condition wiring, query-builder condition inclusion/omission) + updated snapshots across 4 snapshot files
• Requested by: @pyramation
• Session: https://app.devin.ai/sessions/c3e55218c0a94d99a5d678a374506930

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring