Add mutation engine for TypeSpec-to-GraphQL type transformation

[FionaBronwen]

This PR introduces a mutation engine that bridges the gap between TypeSpec's type system and
GraphQL's naming/structural constraints. It builds on @typespec/mutator-framework to apply
GraphQL-specific transformations to TypeSpec types before they're emitted as SDL.

What this does

TypeSpec and GraphQL have different conventions and rules around type naming and structure. For
example:

• TypeSpec uses camelCase for properties, GraphQL enum values use SCREAMING_SNAKE_CASE
• TypeSpec allows unions of scalars, but GraphQL unions can only contain object types
• TypeSpec template instantiations like List<string> need readable names like ListOfString

The mutation engine handles these transformations by defining per-type mutation classes that hook
into the mutator framework's traversal:

• Enum/EnumMember — Sanitizes names to PascalCase (types) and SCREAMING_SNAKE_CASE (values)
• Model/ModelProperty — Sanitizes model and property names for GraphQL compatibility
• Operation — Normalizes operation names; automatically propagates input context to parameters and
  output context to return types
• Scalar — Maps TypeSpec scalars to their GraphQL equivalents via a scalar mapping table
• Union — Detects nullable unions (T | null) and flattens them; wraps scalar variants in synthetic
  object types (since GraphQL unions only allow object members)

Input/output type context splitting

GraphQL distinguishes between input types (used in operation arguments) and output types (used in
return values). The mutation engine handles this via GraphQLMutationOptions, which overrides the
framework's mutationKey to produce separate cached mutations per context ("input" vs "output").

When an operation is mutated, GraphQLOperationMutation overrides mutateParameters() and
mutateReturnType() to inject the appropriate context. The framework's built-in options propagation
carries that context to all nested types automatically.

Also included

• src/lib/type-utils.ts — Shared utilities for name sanitization (toTypeName, toFieldName,
  sanitizeNameForGraphQL), nullable union detection, template name generation, and splitWithAcronyms
  for handling acronyms in casing conversions
• src/lib/scalar-mappings.ts — Complete mapping table from TypeSpec scalars to GraphQL scalar types
  (including int64 → BigInt, float32 → Float, custom scalar specs, etc.)
• 56 tests across type-utils (35) and mutation engine (21)
• Package hygiene: tspMain, node engine bump to >=20, api-extractor.json, consistent casing in test
  helpers

Testing

npx vitest run

[steverice]

What's this used for?

[FionaBronwen]

The emitter uses wrapperModels to register the synthetic wrapper types (e.g. TextUnionVariant { value: String! }) in the schema alongside the union. Without this, the wrapper objects would be
created but never emitted. But like I mentioned below, it sounds like the GraphQL Spec doesn't want us to do this 😅 I'll come up with a better appraoch.

[steverice]

Did we say in the design doc we'd support this this way? I can see it being very surprising that this be the result (and not in a good way). Maybe it needs to be configurable.

[FionaBronwen]

yep! In he union section, it proposes putting wrapper types on scalars since all union member in GraphQL must be models. Although, after looking at the GraphQL spec I see that "The member types of a Union type must all be Object base types; Scalar, Interface and Union types must not be member types of a Union. Similarly, wrapping types must not be member types of a Union." Soooo, maybe we need to rethink this.