Use schema-inferred naming/inflection in graphql-codegen generators

[pyramation]

Use schema-inferred naming in graphql-codegen generators

Summary

The codegen generators (mutations.ts, select.ts) hardcoded all GraphQL operation names, input types, and patch field names via string concatenation (e.g. `create${table.name}`, `${table.name}Filter`). Meanwhile, infer-tables.ts already populates table.query and table.inflection with the actual names discovered from the GraphQL schema via introspection. The generators simply ignored these fields.

This PR introduces a new naming-helpers.ts module (back-ported from Dashboard's query-generator.ts) that prefers schema-discovered names and falls back to local inflection. All hardcoded naming in the generators is replaced with calls to these helpers.

Changes:

• naming-helpers.ts (new): 13 server-aware naming functions (toCamelCasePlural, toCamelCaseSingular, toCreateMutationName, toPatchFieldName, toFilterTypeName, toOrderByTypeName, etc.) with normalizeInflectionValue safety wrapper and guards against naive pluralization drift.
• mutations.ts: All 3 mutation builders (create, update, delete) now use naming helpers for mutation names, input type names, and singular field names. Removed direct inflekt import.
• select.ts: generateIntrospectionSchema, generateSelectQueryAST, generateFindOneQueryAST, generateCountQueryAST all use naming helpers. Patch field name is now entity-specific (e.g. userPatch instead of hardcoded patch). Old toCamelCasePlural/toOrderByTypeName re-exported for backward compat.
• field-selector.ts: isRelationalField now uses a WeakMap-cached Set<string> for O(1) lookups instead of .some() linear scans. getRelatedTableScalarFields also uses Sets for dedup.

Review & Testing Checklist for Human

• Verify toUpdateInputTypeName and toDeleteInputTypeName don't need table parameter. Unlike toCreateInputTypeName which checks table.inflection.createInputType, the update/delete variants are still hardcoded. Check whether TableInflection carries equivalent fields for these and whether they should also be schema-aware.
• Test with a schema that has custom inflection rules. All 301 tests pass, but they likely use schemas where hardcoded names match server names. The real test is a schema with InflektPlugin or custom inflection where table.query.all !== pluralize(camelize(table.name)). Verify generated queries use the correct server names.
• Check the type change in buildPostGraphileUpdate. The return type's variables changed from { input: { id: string | number; patch: Record<string, unknown> } } to { input: { id: string | number } & Record<string, unknown> }. This is more flexible (supports entity-specific patch field names) but consumers who relied on the patch property name in the type will lose that type safety. Verify this is acceptable.
• Verify table.inflection.patchType exists. select.ts line 138 uses table.inflection?.patchType — confirm this field is actually populated by infer-tables.ts or that the fallback to ${modelName}Patch is always correct.

Notes

• Related issue: https://github.com/constructive-io/constructive-planning/issues/651
• This enables codegen to work correctly with any PostGraphile schema that uses custom inflection rules (via graphile-settings/InflektPlugin).
• The naming helpers include guards against naive pluralization ("activitys" → "activities") and miscased server values ("deliveryzones" → "deliveryZones"), but these guards could theoretically reject valid server names in edge cases. Worth spot-checking the guard logic.
• Link to Devin run: https://app.devin.ai/sessions/cc15c94da78646f28f931048c542c26f
• Requested by: @pyramation

[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