Decide whether TypeInstantiation.PrefillCall stays in the generic codegen family or moves builder-side #371

Background

From the critical review of #370 (genericize codegen seams, prep for #349): the three renamed types (ResolvedGeneratedType, TypeInstantiation, GeneratedTypes) are convention-free and generic-shaped — except for one borderline member.

The case: TypeInstantiation.PrefillCall

PrefillCall is the only member of the sealed TypeInstantiation family whose producer and consumers are entirely builder-side today:

• Producer: BuilderScopeResolver (convention detection over the builder's field functions)
• Consumers: FieldPrefillEnhancer, MethodGeneratorUtil (emit the prefill* helper into generated builders)

Its shape is generic — "copy a source value into an empty product through accessor-derived field functions" (the mutable-assembler copy pattern), convention-free since methodName/methodPrefix became record components — but no other codegen beside builders is likely to instantiate it.

Decision needed

Option A (status quo): keep PrefillCall in the generic sealed family. Argument: it is strategy vocabulary, not builder behavior — a non-builder processor simply never instantiates it. No structural cost.

Option B: move PrefillCall processor-side for a strict "codegen contains only what other codegen uses" boundary. Cost: TypeInstantiation is sealed, so permitted subtypes must live in the codegen package — this forces either

1. unsealing TypeInstantiation (open strategy extension point — changes the family from closed to open), or
2. a second strategy type processor-side plus union plumbing at every Optional<TypeInstantiation> usage (ResolvedGeneratedType.funcForPrefilledInstance, switches).

Recommendation

Option A, unless the strict-boundary principle is preferred — in which case Option B deserves its own design pass (open vs. closed strategy family) rather than a mechanical move.