Add Alloy infrastructure, context system, and field components

[FionaBronwen]

Summary

Adds the Alloy component infrastructure for the GraphQL emitter, stacked on PR #89 (structural transforms):

• Alloy JSX dependencies (@alloy-js/core, @alloy-js/graphql), build tooling (alloy build, rollup plugin)
• GraphQLSchemaContext with TypeGraph — imports the interface from mutation-engine/type-graph.ts (single source of truth)
• Field and OperationField components — thin translators from mutated types to Alloy GraphQL SDL components
• Uses resolveGraphQLTypeName (shared lib) for type name resolution and decorator-based nullable state

No GraphQLTypeExpression render-prop component — the mutation pipeline (PRs #88, #89) already handles name composition, nullable unwrapping, record-to-scalar, and union transforms. Components just read type.name and nullable metadata.

Key design decisions

• TypeGraph as the context contract — the mutation pipeline produces a flat namespace of mutated types. Components query the namespace for what they need rather than depending on pre-sorted buckets.
• No type resolution in the renderer — all transforms happen in Phase 1 (mutation engine). Rendering is a direct mapping from mutated types to SDL.
• resolveGraphQLTypeName handles the one exception: std scalars (string → String, int32 → Int) which the mutation engine intentionally leaves untouched to avoid mutating shared compiler singletons.

Test plan

• Field components will be tested end-to-end when the schema orchestrator is wired up (next PR in the chain)
• Existing 201 mutation engine tests pass unchanged
• Type check clean

Stacked on #89.

🤖 Generated with Claude Code

[swatkatz]

TypeGraph.globalNamespace is populated with the pre-mutation namespace (schema.type) in the emitter wiring, but the interface should contain the mutated types instead."

After engine.mutateSchema() runs, the mutated types exist in the MutatedSchema buckets but are never packaged into the TypeGraph. The pinboard pipeline has buildTypeGraph(program, tk, mutatedTypes) which correctly constructs a TypeGraph from mutated types — the open-source emitter should do the same.

This matters because:

• Pinterest's pipeline needs to chain Stage 4 on top of Stage 3's TypeGraph output
• A resolver emitter consuming useGraphQLSchema() would get unmutated types
• useGraphQLSchema() is never called by any component in the chain — symptom of this being wired incorrectly

Fix: after engine.mutateSchema() returns, build a proper TypeGraph from the mutated types and put that on the context. Either move buildTypeGraph into @typespec/graphql or use an equivalent.

[swatkatz]

Architecture discussion

After tracing the full PR chain (#77→#85), here's how I think the pieces should fit together:

Data flow

mutateSchema(program, engine, namespace)
    → MutatedSchema (bucketed mutated types)
    → buildTypeGraph(program, tk, allMutatedTypes)
    → TypeGraph { globalNamespace }  (post-mutation)
    → Renderer walks TypeGraph, renders via Alloy components

TypeGraph wiring

buildTypeGraph (from the pinboard pipeline PR) packages all mutated types into a clean namespace. The emitter should call it after mutateSchema and put the result on context. Currently PR #84 puts schema.type (pre-mutation) which means useGraphQLSchema() returns unmutated types, explaining why no component ever calls it.

Type resolution

GraphQLTypeExpression as a render-prop returning GraphQLTypeInfo adds indirection that doesn't carry its weight. Alloy's <gql.Field> takes a type string + nonNull + nested <gql.Field.List> children. A helper function returning { typeName, nonNull, listLayers: boolean[] } would let Field render Alloy components directly:

const resolved = resolveGraphQLType(property.type, ...);
<gql.Field name={property.name} type={resolved.typeName} nonNull={resolved.nonNull}>
  {resolved.listLayers.reduceRight(
    (inner, layerNonNull) => <gql.Field.List nonNull={layerNonNull}>{inner}</gql.Field.List>,
    undefined
  )}
</gql.Field>

This also fixes the nested list issue (string[][] → [[String!]!]!) since listLayers is an array, not a boolean and other such subtle bugs that might be introduced by adding this indirection.

Component data flow

Components should get their types from TypeGraph.globalNamespace (via useGraphQLSchema() + walking/filtering), not from MutatedSchema buckets threaded through props from the emitter. This keeps the renderer self-contained and makes TypeGraph the real shared contract for downstream consumers (resolver emitter, Pinterest pipeline Stage 4).

What stays the same

• Mutation engine + all mutations (model renaming, input suffix, scalar mapping, union wrapping, etc.)
• mutateSchema orchestration
• Alloy GraphQL components
• Two-phase principle (all naming in mutation, rendering uses type.name)

We should also add tests in each PR to catch edge cases, errors, rather than doing it all at once at the end.

[FionaBronwen]

@swatkatz Additions LGTM! thanks!

[swatkatz]

Since Fiona is the author, she can't officially approve this PR, so I am approving it on her behalf as I wrote the code, so it is fine to swap roles: https://pinterest.slack.com/archives/C08UD3MR5QT/p1781035265891089?thread_ts=1780928581.664069&cid=C08UD3MR5QT